在JavaScript开发与前端工程实践中，获取当前域名是一项基础且关键的操作。最核心、最标准的做法是直接使用 window.location.hostname 属性，这一方法能够精准地提取浏览器地址栏中的主机名部分，不包含端口号、协议名以及路径参数，是绝大多数业务场景下的首选方案，实际开发中往往面临更复杂的需求，例如需要获取带协议的完整源、处理特定端口号、或者在服务端渲染（SSR）环境中兼容获取，这就要求开发者必须深入理解Location对象的各种属性及其适用场景,以确保代码的健壮性与SEO友好性。
深入理解Location对象及其核心属性
要灵活获取域名，首先必须透彻理解浏览器提供的 window.location 对象，这个对象包含了当前URL的所有信息，而不仅仅是域名，对于SEO和业务逻辑而言,区分这些属性至关重要。
window.location.hostname 是获取纯净域名的核心属性，它返回的字符串仅包含主机名，例如访问 https://www.example.com:8080/path 时，它仅返回 www.example.com，这对于判断当前运行环境（如判断是生产环境还是测试环境）非常有用。
window.location.host 则是一个容易与hostname混淆的属性，它返回的是主机名加上端口号，如果URL中包含非标准的端口号（如8080或3000），host 会包含该端口；如果是标准的80端口（HTTP）或443端口（HTTPS），浏览器通常会自动省略，在需要构建API请求地址时，如果后端服务监听在特定端口上，使用 host 属性能避免硬编码端口号带来的维护成本。
window.location.origin 提供了协议、主机名和端口的组合。https://www.example.com，这是在处理跨域请求或拼接相对路径时最安全的属性，因为它自动保留了当前使用的协议（HTTP或HTTPS），避免了混合内容错误，这对于提升网站的安全性和用户体验（E-E-A-T中的体验原则）非常关键。
不同业务场景下的域名获取策略
根据不同的业务需求，单纯获取 hostname 往往是不够的,我们需要制定针对性的获取策略。
动态设置API请求基础URL
在前后端分离的架构中，前端通常需要根据当前域名动态请求后端接口，为了保证环境的一致性，建议使用 window.location.origin 作为基础URL，如果开发环境、测试环境和生产环境共用同一套前端代码，可以通过域名特征进行判断。
如果当前域名包含 dev，则指向开发环境API；否则指向生产环境API，这种基于域名的环境嗅探比硬编码配置更加灵活,减少了发布时的配置出错概率。
获取主域名（顶级域名）用于Cookie共享
在涉及多子域名共享用户登录态（Cookie）的场景下，获取 hostname 往往是不够的，因为我们需要的是主域名，当前域名是 app.example.com，为了将Cookie写入 .example.com 供所有子域名共享，我们需要剥离子域名。
这可以通过字符串处理逻辑实现：将域名按点分割，如果数组长度大于2，则取最后两部分组合。这种处理方式对于大型多站点矩阵的SSO（单点登录）系统至关重要，能够确保用户在跨域访问时保持登录状态,显著提升用户体验。
SEO优化中的规范链接设置
对于SEO而言，避免重复内容是核心原则。www.example.com 和 example.com 都能访问同一页面，搜索引擎会认为这是两个不同的URL，从而分散权重，利用JavaScript获取当前域名，我们可以动态检测并重定向。
我们希望统一使用 www 开头的域名，可以在页面加载时判断 hostname 是否以 www 开头，如果不包含，则使用 window.location.replace 重定向到带 www 的地址。使用 replace 方法而非 href 跳转，是为了避免用户点击“后退”按钮时再次触发重定向死循环,这种细节处理体现了极高的专业度。
跨域安全性与服务端渲染（SSR）的兼容方案
在讨论前端技术时,不能忽视安全性与现代框架的兼容性。
安全性方面，虽然 window.location 是只读对象，但在进行DOM操作或拼接URL时，必须警惕XSS（跨站脚本攻击），如果从URL参数中获取部分信息并拼接到域名中进行跳转，必须对输入进行严格的校验和转义。document.domain 属性虽然可以用于跨域iframe通信，将其设置为当前域名的“父级”可以实现松散同源策略，但这在现代浏览器中限制颇多，且存在安全风险，不建议在常规业务中仅为了获取域名而操作 document.domain。
服务端渲染（SSR）方面，随着Next.js、Nuxt.js等框架的普及，代码可能在服务端执行，在Node.js环境中，window 对象是不存在的，直接调用 window.location.hostname 会导致报错崩溃。
编写通用的获取域名函数必须具备环境判断能力，专业的解决方案是封装一个工具函数：首先检测 typeof window !== 'undefined'，如果存在则返回 window.location.hostname；如果不存在（处于Node.js环境），则从请求头中获取 Host 字段。这种同构代码的编写能力是衡量高级前端工程师的重要标准，它确保了代码在浏览器端和服务器端的平滑运行,保障了SEO爬虫能够正确解析页面信息。
专业解决方案：封装健壮的域名获取工具
为了应对上述所有场景，提供一个封装良好的工具函数是最佳实践，该函数应支持返回主域名、带协议域名等不同格式。
/**
* 获取当前域名的工具函数
* @param {Object} options 配置选项
* @param {boolean} options.includeProtocol 是否包含协议
* @param {boolean} options.includePort 是否包含端口
* @param {boolean} options.mainDomain 是否仅返回主域名（去除子域名）
* @returns {string} 处理后的域名
*/
function getCurrentDomain(options = {}) {
const { includeProtocol = false, includePort = false, mainDomain = false } = options;
// 兼容SSR环境判断
if (typeof window === 'undefined') {
return ''; // 或在服务端通过上下文获取
}
let domain = includePort ? window.location.host : window.location.hostname;
if (mainDomain) {
const parts = domain.split('.');
if (parts.length > 2) {
// 简单逻辑：取最后两部分，实际项目中可能需要更复杂的公共后缀列表判断
domain = parts.slice(-2).join('.');
}
}
if (includeProtocol) {
domain = window.location.protocol + '//' + domain;
}
return domain;
}
通过上述代码，开发者可以极其灵活地获取各种形式的域名，既满足了业务逻辑的复杂性,又通过参数控制保证了代码的复用性。
相关问答
Q1：在JavaScript中，window.location.href 和 window.location.origin 有什么本质区别，在SEO中哪个更适合用于构建链接？
A1： window.location.href 返回的是完整的URL，包含协议、域名、端口、路径以及查询参数等所有信息；而 window.location.origin 仅返回协议、域名和端口，在SEO中，如果需要构建页面内部的跳转链接或API请求，使用 origin 拼接路径是更好的选择，因为它更简洁且避免了携带不必要的查询参数，有助于保持URL的整洁和权重集中，只有在需要保留当前URL所有状态进行完整跳转时，才使用 href。
Q2：如何解决在本地开发环境（localhost）和生产环境使用不同域名时的接口请求跨域问题？
A2： 这是一个常见的开发痛点，在生产环境，前端和后端通常部署在同一主域下或配置了CORS，直接使用 window.location.origin 请求接口即可，在本地开发环境（localhost），由于浏览器安全策略，请求生产环境接口往往会跨域，专业的解决方案是：在开发环境中使用代理（如Webpack DevServer的proxy配置），将特定路径的请求转发到后端服务器，这样在浏览器看来请求依然是发往 localhost 的，从而绕过浏览器的同源策略限制，而在代码层面，请求的目标地址依然可以统一写为相对路径或基于 origin 的路径。
希望这篇文章能帮助你更好地理解JavaScript中获取域名的各种细节，如果你在项目实战中遇到了关于跨域、SSR域名获取或SEO重定向的棘手问题，欢迎在评论区留言,我们可以一起探讨更优的解决方案。
