在H5移动端页面开发中,获取当前访问的域名是进行接口请求配置、数据统计上报以及多环境切换的基础操作。实现这一功能最核心、最高效且兼容性最好的方案是直接利用浏览器原生提供的window.location对象，通过该对象，开发者不仅可以精准提取纯域名，还能根据实际业务需求获取包含端口号的主机名或完整的协议头，针对不同的开发场景，如纯静态页面、单页应用（SPA）或混合开发环境，获取域名的方式略有差异，但本质上都是对浏览器地址栏信息的解析，以下将从基础方法、进阶场景、混合开发处理及安全规范四个维度，详细解析H5页面获取域名的专业实践。
基础获取方法：window.location对象
对于绝大多数标准的H5页面,JavaScript的window.location对象是获取域名信息的首选方案，该对象包含了当前URL的完整信息，无需引入任何第三方库即可直接调用。
获取纯域名（不包含端口和协议）
使用window.location.hostname属性，这是最常用的方式，它返回的是网络位置中的域名部分，如果当前URL是https://www.example.com:8080/path，那么window.location.hostname将返回www.example.com，这种方式适用于需要根据域名进行特定逻辑判断的场景，比如判断是否在正式环境。
获取主机名（包含端口号）
使用**window.location.host**属性，与hostname不同，host属性会包含端口号（如果存在），在Web开发中，非标准端口（如8080、3000等）在本地开发或特殊部署环境中非常常见，如果后端接口依赖于Host头部进行路由转发，或者前端需要拼接完整的请求地址，使用host属性能避免因端口缺失导致的请求失败，URL为http://localhost:3000，host将返回localhost:3000。
获取源（协议+主机名+端口）
使用**window.location.origin**属性，这是一个非常实用的属性，它直接返回协议、域名和端口的组合，即URL的基础部分。https://api.example.com，在发起AJAX请求或Fetch请求时，直接使用origin作为Base URL是最为便捷的，它能自动适配HTTP与HTTPS协议，避免混合内容（Mixed Content）安全错误。
进阶处理方案：URL对象与正则提取
虽然window.location能够解决大部分问题，但在某些复杂场景下，例如需要解析非当前页面的URL字符串，或者处理老旧浏览器的兼容性问题时，需要采用更灵活的进阶方案。
使用现代URL API
现代浏览器（包括所有主流移动端浏览器内核）均支持URL构造函数，如果需要获取的域名不是当前页面的域名，而是一个动态传入的URL字符串，URL API是最佳选择。
代码示例如下：
const targetUrl = 'https://m.example.com/user?id=123'; const urlObj = new URL(targetUrl); const domain = urlObj.hostname; // 返回 m.example.com
这种方法比正则表达式更健壮,能够自动处理各种边缘情况，且代码可读性更高。
正则表达式提取
在极端受限的环境下，或者需要对特定格式的字符串进行批量提取时，正则表达式依然是一个强有力的工具，一个通用的提取域名的正则逻辑是匹配之后到下一个或结尾之间的内容。
/https?:\/\/([^\/]+)/，通过捕获组可以提取出包含端口的Host部分，再进一步处理即可得到纯域名。但在实际工程中，建议优先使用上述的原生API，正则维护成本较高且容易出错。
混合开发环境：WebView与JSBridge的特殊处理
在移动端混合开发中,H5页面通常运行在App的WebView容器中，获取域名可能会遇到“伪协议”或本地文件路径的问题。
file:// 协议的陷阱
当H5页面被打包进App本地资源包中加载时，其URL往往以file:///开头。window.location.hostname可能为空字符串或者返回手机设备的文件路径，这显然不是我们期望的业务域名。
解决方案： 在这种场景下，不能依赖浏览器的地址栏信息，必须通过JSBridge与原生客户端进行通信，由App端在加载H5页面时，通过初始化方法将当前App运行的API域名注入到H5的全局变量中，或者通过特定的JSBridge接口供H5调用获取。
动态注入域名配置
专业的混合开发架构通常会在WebView初始化阶段注入配置信息。
// 假设由原生注入
window.AppConfig = {
baseUrl: 'https://api.app.com',
host: 'app.com'
};
H5页面在获取域名时,应优先判断window.AppConfig是否存在，如果存在，则直接使用配置中的域名；如果不存在（如在普通浏览器中调试），则降级使用window.location，这种双模获取机制是保障H5页面在App内和浏览器外都能稳定运行的关键。
安全规范与最佳实践
获取域名不仅仅是一个技术实现问题,更涉及到前端的安全性和代码的健壮性。
防止XSS攻击
如果域名的获取过程涉及到从URL参数中读取（例如?domain=xxx.com）并直接使用，必须进行严格的校验。切勿直接将未经验证的URL参数作为跳转目标或接口请求的域名，否则极易造成开放重定向或XSS攻击，应维护一个白名单列表，仅当获取到的域名在白名单内时才执行业务逻辑。
环境区分
在专业的前端工程化体系中，通常不建议在代码运行时动态去“猜”域名，更好的做法是利用Webpack或Vite等构建工具，在编译打包阶段根据环境变量注入不同的域名常量。运行时获取域名应仅作为兜底方案或用于数据统计上报，而不应作为核心业务逻辑的唯一依赖。
协议自适应
在获取域名时，务必注意协议的一致性，如果页面是HTTPS加载的，获取的域名用于接口请求时也必须是HTTPS，否则浏览器会拦截请求，使用window.location.protocol可以动态获取当前协议（http:或https:），确保请求协议与页面协议一致。
相关问答
Q1：在H5页面中，window.location.host 和 window.location.hostname 有什么本质区别？
A： 两者的主要区别在于是否包含端口号。window.location.hostname 仅返回域名（如 www.example.com），而 window.location.host 返回域名加上端口号（如 www.example.com:8080），如果你的服务部署在标准的80端口（HTTP）或443端口（HTTPS），浏览器通常会隐藏端口，两者返回值相同；但在本地开发或使用了非标准端口的生产环境时，必须使用 host 属性来确保请求地址的完整性。
Q2：为什么我的H5页面在微信内置浏览器中能获取域名，但在App的WebView中获取为空？
A： 这通常是因为App加载H5页面时使用的是本地文件路径，即URL以 file:// 开头，在这种协议下，window.location 对象没有网络意义上的域名，解决此问题的标准做法是使用 JSBridge，让原生客户端将正确的业务域名通过参数传递给H5页面，或者由H5主动调用原生接口获取当前App的配置信息，而不是依赖浏览器的Location对象。
—能帮助您解决H5页面开发中遇到的域名获取问题，如果您在实际项目中遇到了特殊的协议头处理或跨域场景，欢迎在评论区分享您的具体案例，我们可以进一步探讨解决方案。
