replaceState 不会触发页面刷新。它仅修改 URL 和历史栈顶状态，不重新加载页面、不触发 popstate 事件、无网络请求，适用于静默清理参数；应使用 URL 构造函数安全操作 searchParams，避免手动拼接破坏编码；需在 DOM 就绪后执行，防止 Safari 等丢弃状态；仅作用于当前页 URL，不影响重定向链上游或 document.referrer。
replaceState 会触发页面刷新吗
不会。调用 history.replaceState 只修改浏览器地址栏 URL 和历史记录栈顶的状态对象，不重新加载页面、不触发 popstate 事件，也不会导致任何网络请求。这是它和 location.href 或 history.pushState 的关键区别之一——适合静默清理 URL 参数。
如何安全移除 coupon=xxx 这类参数而不影响其他查询参数
直接拼接字符串或正则替换容易破坏 URL 编码（比如把 coupon=10%25OFF 中的 %25 错误切开）。正确做法是用 URL 构造函数解析，再操作 searchParams：
const url = new URL(window.location.href);
url.searchParams.delete('coupon');
// 保留其他参数，如 utm_source、ref 等
history.replaceState(null, '', url.toString());
注意：url.toString() 会自动处理编码，比手写 url.origin + url.pathname + '?' + newSearchParams(...) 更可靠。
为什么 replaceState 后前进/后退按钮失效了
常见原因是调用时机不对。如果在页面加载完成前（比如 DOM 尚未 ready、或 React/Vue 组件还没挂载）就执行 replaceState，某些浏览器（尤其是 Safari）可能丢弃该状态变更，导致历史栈异常。
稳妥做法：
- 确保在
DOMContentLoaded或框架的mounted/useEffect中执行 - 避免在
popstate事件回调里反复调用replaceState，否则可能陷入循环 - 检查是否重复执行：同一页面多次运行该逻辑，会导致 URL 被反复改写（虽然无害，但日志难排查）
推广链接带多层重定向时，replaceState 还有效吗
有效，但只作用于当前最终页面的 URL。如果推广链接是 a.com/?coupon=A → b.com/?ref=a → c.com/?utm=1&coupon=B，你在 c.com 上调用 replaceState，只能清理 c.com 的 coupon，前面跳转链中的参数不受影响。
这意味着：
- 必须在目标落地页（用户真正看到的页面）执行，不能放在中转页
- 如果落地页是单页应用（SPA），需监听路由变化，在每次匹配到含
coupon的路径后立即清理 - 服务端无法感知前端的
replaceState，所以分享新链接时仍要确保后端生成的初始 URL 不带过期参数
最易被忽略的一点：replaceState 不改变 document.referrer，也不影响 GA / Firebase 的来源追踪——那些依赖的是导航发起时的原始 URL，不是当前地址栏显示的值。
