replaceState可静默清理URL参数而不跳转，需用URLSearchParams安全操作，并在DOM加载后执行，避免被服务端重定向覆盖。
replaceState 会改变 URL 但不触发页面跳转，适合静默清理参数
这是最核心的前提：如果你希望用户停留在当前页、不刷新、不重发请求，只改掉地址栏里难看的 ?utm_source=old&utm_medium=email&ref=abc123 这类推广参数，history.replaceState 是唯一合理选择。它不会像 location.href 那样触发导航，也不会像 pushState 那样多留一条历史记录。
用 URLSearchParams 安全提取并过滤参数，别手写正则删 query
手动用 String.prototype.replace() 去掉参数极易出错——比如误删值里带 & 的参数、破坏编码（%20 变成空格）、漏掉 # 后的 hash。正确做法是走标准 API：
const url = new URL(window.location.href);
const params = new URLSearchParams(url.search);
// 删除指定推广参数，保留其他所有
params.delete('utm_source');
params.delete('utm_medium');
params.delete('utm_campaign');
params.delete('ref');
params.delete('gclid');
// 重建 search，自动处理编码和拼接
url.search = params.toString();
// 替换当前历史状态
history.replaceState(null, '', url.toString());
必须在页面加载完成后再执行，否则可能被服务端重定向覆盖
常见坑：把这段逻辑放在 <script></script> 标签里且没加时机控制，结果脚本一执行，后端重定向（如登录跳转、A/B 测试路由）就把刚修好的 URL 又刷掉了。稳妥做法是：
- 放在
window.addEventListener('load', ...)或document.addEventListener('DOMContentLoaded', ...)里 - 如果项目用了 React/Vue，确保在组件挂载后（如
useEffect(() => { ... }, [])）再调用 - 若页面本身依赖某些 query 参数做初始化（比如
?debug=true），记得在delete前先读取并缓存关键值
replaceState 后 history.state 为 null 不影响，但要注意 popstate 监听器兼容性
调用 history.replaceState(null, '', ...) 后，history.state 确实变成 null，这完全正常——你没传新 state，浏览器就清空它。只要不依赖 history.state 做逻辑判断，就没事。但要注意：
- 如果页面监听了
popstate事件（比如实现自定义返回逻辑），要确保 handler 能处理event.state === null的情况 - 部分老版本 iOS Safari 对
replaceState修改search的响应有延迟，建议加个setTimeout(() => console.log(location.href), 0)做简单验证 - 服务端做 SEO 渲染时，仍需按原始 URL 处理，前端改 URL 不影响 SSR 行为
实际生效的关键往往不在 replaceState 本身，而在你是否等对了时机、是否用对了 URL 解析方式、以及是否意识到服务端与前端 URL 状态天然不同步。
