前端获取当前页面URL

1. 需求场景与核心思路

页面地址的获取在前端开发里属于“高频且零门槛”的操作，随便一搜能看到各种片段式的写法，但真到了业务里往往不是复制一行代码就能完事的。有人要拿它做分享链接，有人要拿它回传埋点数据，还有人要处理多级路由下的参数同步，需求五花八门，但起点都一样：怎么稳定地取出当前页面的完整地址、协议、域名、路径和查询参数。

先把最基础的工具链摆出来。浏览器环境下，window.location就是开发者接触页面地址的主入口，它不是一个函数，而是一个包含若干属性的对象。直接访问window.location.href能拿到完整地址，比如https://example.com:8080/path/page?a=1&b=2#section。但实际项目里几乎没人会只取一个完整字符串，更多时候需要拆开用：协议、主机名、端口、路径、查询串、哈希，各取所需。

// 最直接的完整地址 const fullUrl = window.location.href; // 拆开看各个部分 console.log(window.location.protocol); // "https:" console.log(window.location.hostname); // "example.com" console.log(window.location.port); // "8080" console.log(window.location.pathname); // "/path/page" console.log(window.location.search); // "?a=1&b=2" console.log(window.location.hash); // "#section"

这套 API 看起来简单，但有几个细节很容易栽跟头。

第一个细节是port属性。默认端口情况下（HTTP 的 80 和 HTTPS 的 443），浏览器返回的是空字符串，而不是"80"或"443"。如果你要做端口拼接，必须对空值做兜底，否则拼出来的 URL 会带一个裸冒号。

第二个细节是hash与search的顺序。地址中查询串出现在路径之后、哈希之前，但window.location的search和hash是独立属性，互不包含。取参数时如果把哈希也带进去，解析逻辑就会出错。比如上面的例子，直接用search拿到的只有?a=1&b=2，不会包含#section。

第三个细节是方案的取舍。window.location能拆出结构化数据，但如果只是想把当前地址拼成可分享或可保存的字符串，用window.location.href就够，没必要拆完再拼。反过来，如果要做不同环境下协议自适应，就得先看protocol，再决定是否要写死协议头。

很多初学者会混淆window.location和document.URL。document.URL返回的也是当前页面的完整地址，但它是只读的，而且不同浏览器在哈希变化时的表现不完全一致。比较稳妥的结论是：读地址用window.location，改地址用window.location或history，document.URL仅适合极简场景下的只读取值。

这套基础能力在不同框架里会有封装差异，但底层规则一致。下面从实战角度把“取 URL”这件事拆成几个常见需求来展开。

2. 完整地址与各分段参数的取值方式

2.1 取完整地址：href、toString、String 的差异

window.location.href是最常见的完整地址获取方式，但它不是唯一方式。window.location.toString()也能返回同样的字符串，String(window.location)也能。三者在绝大多数现代浏览器里结果一致，但在语义上有区别：href是属性读取，toString是方法调用，String()则是强转。

实际开发里没必要纠结三者性能差异，统一用href就行。但有一种情况要小心：某些框架（尤其是 SSR 场景）会在服务端注入假的location对象，这时候href可能是一个兼容占位值，需要根据运行环境判断是否可以直接用。如果是纯浏览器环境，window.location.href是稳定可靠的。

// 推荐写法 const currentUrl = window.location.href; // 等价写法，不推荐混用 const currentUrl2 = window.location.toString(); const currentUrl3 = String(window.location); // 判断是否纯浏览器环境 if (typeof window !== 'undefined' && window.location) { // 此时才能安全读取 }

2.2 取协议与域名：protocol、hostname、host 的边界

protocol返回带冒号的协议名，比如https:。hostname只返回域名部分，不包含端口。host则返回域名加端口。三个属性容易混淆，用一张表列清楚：

实际项目里拼分享链接时，origin是最好用的，因为协议、域名、端口一次性拿到，不会漏掉端口。但origin在部分旧浏览器的兼容性上不如host，如果项目有老旧内核需求，建议用protocol + '//' + host拼接。

// 推荐：用 origin const origin = window.location.origin; // 兼容写法：手动拼 const originCompat = window.location.protocol + '//' + window.location.host;

2.3 取路径与查询参数：pathname、search、URLSearchParams

pathname返回路径部分，以/开头。search返回查询串，以?开头。处理查询参数时，不要自己写正则去拆，浏览器原生提供了URLSearchParams，使用体验非常顺滑。

// 拿完整查询串 const searchStr = window.location.search; // "?a=1&b=2" // 原生解析查询参数 const params = new URLSearchParams(window.location.search); const a = params.get('a'); // "1" // 判断参数是否存在 const hasB = params.has('b'); // true // 遍历所有参数 params.forEach((value, key) => { console.log(key, value); });

URLSearchParams的一个隐藏优势是它对 URL 编码做了自动处理。比如参数值里带了中文或特殊字符，直接用get拿到的就是解码后的结果，不用自己再decodeURIComponent。但要注意URLSearchParams初始化时如果用完整href而不是search，它也能处理，因为它会自动忽略?之前的路径部分，不过从语义清晰度考虑，还是建议传入search。

2.4 取哈希值：hash、location.hash 的注意事项

hash返回带#的值，比如#section。如果你只需要锚点名，要自己去掉#。

const hash = window.location.hash; // "#section" const hashName = hash.replace('#', ''); // "section" // 如果哈希可能为空 const cleanHash = window.location.hash.replace(/^#/, '') || null;

哈希在单页应用里承担着路由同步的作用，很多框架会把路由状态编码在哈希里，比如#/user/123。这时候不要简单用replace去拿，而要配合路由库的解析方法。手动解析哈希路径很容易踩到编码坑，尤其当参数里包含嵌套对象时，官方路由 API 会比自己拆字符串更可靠。

3. 不同场景下的实战封装

3.1 分享链接与传播场景

做活动页分享时，经常需要把当前地址复制给用户，或者把地址塞进二维码。这时要的是完整地址，并且要保证协议正确。如果页面同时支持 HTTPS 和 HTTP（比如本地开发是 HTTP，线上是 HTTPS），用window.location.href就天然正确。

function buildShareUrl() { const url = window.location.href; // 如果地址带敏感参数，先剔除再分享 const cleanUrl = removeSensitiveParams(url); return { text: '分享内容', url: cleanUrl }; } function removeSensitiveParams(url) { const u = new URL(url); u.searchParams.delete('token'); u.searchParams.delete('userId'); return u.toString(); }

这里有个经验之谈：分享链接里经常带着token、userId这类参数，直接原样分享会有隐私泄露风险。用URL对象操作查询参数非常方便，new URL(url)之后直接searchParams.delete干净利落，最后toString()返回的就是剔除了敏感项的完整地址。

3.2 埋点上报与页面统计场景

埋点上报时，后端往往需要区分来源页面和当前页面，这时候要拿的不是完整 URL，而是经过裁剪的 pathname + search。如果直接把完整 URL 上报，可能会带一些无关紧要的 utm 参数，导致统计数据被污染。

function getPageIdentity() { const { pathname, search } = window.location; return pathname + search; } // 带协议域名的完整标识 function getFullPageUrl() { return window.location.origin + window.location.pathname + window.location.search; }

推荐上报时至少包含两组数据：一组是pathname + search作为页面身份标识，另一组是referrer作为来源。document.referrer能拿到上一个页面地址，但这个值在不同跳转方式下可能为空。比如直接输入地址、刷新页面、或者从 App 外部唤起时，referrer经常是空的。埋点统计这类场景要提前和后端约定空值策略，而不是在代码里强行造一个伪来源。

3.3 前端路由与页面状态同步场景

单页应用里，当前 URL 的变化往往代表路由状态变化。不同路由模式下，取值侧重点不同：

• Hash 模式：路由在hash里，状态同步靠hashchange事件。
• History 模式：路由在pathname里，状态同步靠popstate事件。

// 监听 hash 变化 window.addEventListener('hashchange', () => { const currentHash = window.location.hash; // 更新页面状态 updateStateByHash(currentHash); }); // 监听 history 变化 window.addEventListener('popstate', () => { const currentPath = window.location.pathname; // 更新页面状态 updateStateByPath(currentPath); });

实际项目中，框架会帮我们封装好这一层，但理解底层事件机制对你排查“页面刷新后状态丢失”这类问题非常有帮助。比如 History 模式下，pushState并不会触发popstate，只有浏览器前进后退或手动调用history.back()、history.forward()才会触发。如果你在代码里history.pushState之后立刻去读 URL，发现是新的，但监听器没反应，这是正常现象，不是 bug。

3.4 多环境切换与调试场景

本地开发、测试环境、生产环境的域名可能完全不同。调试弹窗或埋点验证时，需要动态判断当前环境。获取 URL 后做环境判断是常规操作：

function getEnv() { const host = window.location.hostname; if (host.includes('localhost') || host.includes('127.0.0.1')) { return 'dev'; } if (host.includes('test.')) { return 'test'; } return 'prod'; }

这种判断方式很朴素，但足够用。重点是不要在多个文件里各写一套，最好统一封装成工具函数，避免不同页面判断逻辑不一致。有一点要注意：域名判断依赖字符串包含，如果域名里本身就带有test字样，生产环境也会被误判。更稳妥的做法是走配置中心或构建时注入的环境变量，而不是运行时猜域名。

4. 避坑指南与常见问题实录

4.1 哈希导致的参数解析错乱

有个高频坑：地址是https://example.com/path?a=1#/detail?b=2。这里路径后的?a=1是正经查询参数，哈希里的?b=2是前端路由内部参数。如果用new URL(window.location.href)去解析，searchParams.get('a')能拿到1，但searchParams.get('b')拿不到，因为b在哈希里，不在查询串里。

这个场景在单页应用里非常常见。排查思路很简单：先确认哈希里有没有再带一层参数。有的话，解析业务参数要分两层处理，一层解析 search，一层解析 hash 内容。

// 分层解析 const queryParams = new URLSearchParams(window.location.search); const hashPart = window.location.hash; // "#/detail?b=2" // 如果哈希里还有查询参数 const hashQueryIndex = hashPart.indexOf('?'); if (hashQueryIndex !== -1) { const hashQuery = hashPart.slice(hashQueryIndex + 1); const hashParams = new URLSearchParams(hashQuery); console.log(hashParams.get('b')); // "2" }

4.2 二维码与短链接场景的端口遗漏

拼二维码内容时，有人习惯写死域名，结果本地环境带端口，线上没端口，导致生成的二维码在线上打不开。正确的做法是永远基于当前location动态拼：

function buildQrContent() { const base = window.location.origin; // 自动带上非默认端口 return base + window.location.pathname; }

origin会自动处理端口问题，默认端口不显示，非默认端口自动带上。而且它天然包含正确的协议，不会出现线上页面却生成http连接的问题。

4.3 相对路径与绝对路径的误判

有时你拿到的地址不是完整的href，而是window.location.pathname这种相对路径。后端或第三方平台要求传完整地址，但前端只传了路径，就会造成跳转失败或数据缺失。判断标准很简单：需要跳转或分享时一定是完整地址；只是做页面内部标识时，路径加参数足够。

// 封装时明确区分两种输出 function getFullUrl() { return window.location.href; } function getPageKey() { return window.location.pathname + window.location.search; }

4.4 常见问题速查表

4.5 一个容易被忽略的细节：URL 对象与 location 的差异

new URL(window.location.href)和window.location在属性上很像，但有一个关键差异：URL对象是普通对象，改了它的属性不会影响当前页面地址；window.location是浏览器特殊对象，赋值或修改某些属性会直接触发页面跳转。

// 错误示范：以为改了 location 的属性就能改页面 URL const url = new URL(window.location.href); url.pathname = '/new'; // 这只是改了内存里的对象，页面无变化 // 正确跳转：给 location 赋值 // window.location.href = '/new'; // 会触发页面跳转

这个差异在编写工具函数时要刻在脑子里。如果你只是想把当前 URL 拷贝一份做字符串处理，用new URL(window.location.href)最安全；如果你确实要跳转，才去动window.location。

5. 不同框架中的封装与扩展

5.1 React 与 Vue 中的统一封装

React 和 Vue 本身不限制你怎么取 URL，但最佳实践是封装成一个工具函数，或者放进公共 hooks / composables。React 里常见的封装：

// useCurrentUrl.js import { useState, useEffect } from 'react'; export function useCurrentUrl() { const [url, setUrl] = useState(window.location.href); useEffect(() => { const handlePopState = () => setUrl(window.location.href); const handleHashChange = () => setUrl(window.location.href); window.addEventListener('popstate', handlePopState); window.addEventListener('hashchange', handleHashChange); return () => { window.removeEventListener('popstate', handlePopState); window.removeEventListener('hashchange', handleHashChange); }; }, []); return url; }

Vue 3 组合式函数同理：

// useCurrentUrl.js import { ref, onMounted, onBeforeUnmount } from 'vue'; export function useCurrentUrl() { const url = ref(window.location.href); const update = () => { url.value = window.location.href; }; onMounted(() => { window.addEventListener('popstate', update); window.addEventListener('hashchange', update); }); onBeforeUnmount(() => { window.removeEventListener('popstate', update); window.removeEventListener('hashchange', update); }); return url; }

封装的核心逻辑是让 URL 变成响应式数据，页面路由变化时组件自动拿到新地址。但要注意：pushState不会触发popstate，所以如果你在代码里手动pushState，需要手动调用更新函数。

5.2 小程序与 WebView 场景的差异

小程序环境没有window对象，不能直接使用window.location.href。在 WebView 内嵌 H5 页面时，window.location.href可用，但部分 Android WebView 对hashchange的支持不一致，需要额外用轮询或定时器做兜底。

// 兼容 WebView 的 hash 监听 function watchHash(callback) { let lastHash = window.location.hash; const checkHash = () => { const currentHash = window.location.hash; if (currentHash !== lastHash) { lastHash = currentHash; callback(currentHash); } }; window.addEventListener('hashchange', checkHash); // 部分 WebView 兜底轮询 const timer = setInterval(checkHash, 300); return () => { window.removeEventListener('hashchange', checkHash); clearInterval(timer); }; }

这种兜底方案宁可不用也不建议乱用，因为 300ms 的轮询在单页应用里会带来额外开销。只有当你确认目标 WebView 确实有问题时才加。

5.3 服务端渲染框架中的读取策略

服务端渲染框架里，直接在组件的顶层读取window.location.href会报错，因为服务端没有window。推荐的做法是把读取动作放到useEffect或onMounted里，确保只在浏览器端执行。

// 错误示范 // const url = window.location.href; // 服务端直接崩 // 正确示范：懒加载 let currentUrl = ''; if (typeof window !== 'undefined') { currentUrl = window.location.href; }

更规范的做法是用官方提供的生命周期或状态管理方案。但核心原则就一条：不要信任代码的执行环境，读取前先判断typeof window。

6. 动态更新 URL 的配套技巧

获取 URL 是入口，很多业务最终要落到更新 URL。看清location和history的分工对日常开发很有帮助。

window.location.assign(url)会加载新文档，会在浏览器历史里留下记录，用户还能点返回。window.location.replace(url)也会加载新文档，但当前页面不会留在历史里。history.pushState(state, '', url)则完全不一样，它只改地址栏，不触发页面刷新，可以做到无刷新更新 URL。

// 跳转页面，保留历史记录 window.location.assign('/path/new'); // 跳转页面，替换当前历史记录 window.location.replace('/path/new'); // 无刷新更新 URL window.history.pushState({}, '', '/path/new');

这里最容易踩的坑是：只改window.location.href会导致整页刷新，丢失当前页面状态。如果你想在不动页面的情况下同步 URL，必须用pushState或replaceState。同理，pushState不会触发popstate，所以在自定义路由状态同步时要手动触发自己的逻辑。

// 手动更新并通知监听者 function updateUrlWithoutReload(newPath) { window.history.pushState({}, '', newPath); // 手动触发自己的回调 handleRouteUpdate(); }

实际运营活动页里，这种无刷新更新 URL 的方式非常常用，比如点击筛选条件后，把筛选参数写进 URL，页面不刷新，但用户刷新后还能保持筛选状态。实现了“地址即状态”的效果，大大提升交互体验。

6.1 打开新窗口与当前页跳转的选择

有些场景要打开新标签页，有些要在当前页跳。前者用window.open(url)，后者用location或history。但要记住：window.open可能被浏览器弹窗拦截，尤其是非用户手势触发的调用。安全的做法是把跳转绑定在用户点击事件里。

// 用户点击时打开 button.addEventListener('click', () => { window.open('https://example.com', '_blank'); });

如果是异步请求完成后才拿到跳转地址，建议不要用window.open，而是先创建一个隐藏的<a>标签并模拟点击：

function openAfterAsync(url) { const a = document.createElement('a'); a.href = url; a.target = '_blank'; document.body.appendChild(a); a.click(); document.body.removeChild(a); }

这种方式能规避大部分浏览器的弹窗拦截策略。

7. 实际项目中的经验总结

前端获取当前页面 URL，表面看是一个 API 调用，真正写起来要兼顾环境差异、框架差异、路由模式差异、参数编码差异。我个人在项目里沉淀下来的几点经验：

第一，统一封装。不要在业务代码里到处写window.location.href，至少封装一个getUrlHelper()，把完整地址、页面标识、查询参数对象、环境判断全部放在一起，后续维护成本会低很多。

export function getUrlHelper() { const { protocol, host, pathname, search, hash, origin } = window.location; return { fullUrl: window.location.href, origin, protocol, host, pathname, search, hash, query: Object.fromEntries(new URLSearchParams(search)), hashPath: hash.replace(/^#/, '') }; }

第二，区分“页面地址”和“页面标识”。埋点、分享、路由同步、调试，用途不同，取的数据粒度不同。页面地址是完整 href，页面标识是 pathname + search。有些场景还要单独区分是否带 hash，不要一刀切。

第三，警惕敏感参数。只要 URL 要分享或上报，就要考虑是不是带了 token、userId、手机号等信息。哪怕是内部系统，也要养成“先清理后使用”的习惯。

第四，测试时把各种形态的 URL 都跑一遍，尤其注意带端口、带 hash、带编码参数、无查询串、无哈希这些组合。很多线上问题都是“本地只有一个 URL 形态，线上各种形态都有”导致的。

第五，如果项目同时存在 fetch、路由、WebView，要分别验证。曾经遇到一个场景，WebView 内页面用window.location.href拿到的地址是客户端注入的中间页，跟实际用户看到的地址差一截。这种偏差只有真机调试才能发现。

最后，建议在团队内部维护一个url-utils.js，把上述逻辑全部收敛，包括环境判断、敏感参数清理、hash 兼容解析、WebView 兜底监听。这样每个人写业务的时候只需要调用现成函数，不会各写一套，也不会因为某个人忘了处理哈希而线上翻车。