urlsearchparams 构造函数仅解析 query string（如?a=1&b=2），不支持完整 url；传入含协议域名的字符串会导致错误解析。
直接用 URL 构造函数 + URLSearchParams 是目前最可靠、最不易出错的方式。手动拼接或正则替换 query 字符串，在遇到中文、空格、&、=、% 时几乎必然崩溃。
构造 URL 对象必须传完整 URL 字符串
很多人卡在这一步：传了相对路径却没给 base，结果报 TypeError: Invalid URL。
-
new URL("/api/list?x=1")❌ 报错 —— 缺协议和主机 -
new URL("https://api.example.com/api/list?x=1")✅ 正确 -
new URL("/api/list?x=1", location.origin)✅ 正确（推荐用于同源请求） -
new URL("/api/list", "https://api.example.com")✅ 正确（base 必须含协议）
注意：location.origin 是最安全的 base 来源，它不含端口（除非非标准），且始终合法；别用 location.href 或 window.location 直接当 base，容易带 hash 或 query 导致意外解析。
修改查询参数只能通过 searchParams 实例
url.search 是只读字符串，直接赋值如 url.search = "?a=1&b=2" 会清空原有逻辑结构，且无法处理编码、重复键等边界情况。
-
url.searchParams.set("page", "3")→ 覆盖所有page参数（只留一个） -
url.searchParams.append("tag", "react")→ 新增，支持多值：?tag=vue&tag=react -
url.searchParams.delete("sort")→ 彻底移除所有sort=xxx -
url.searchParams.get("limit")→ 只取第一个值；url.searchParams.getAll("filter")→ 取全部（适合复选框场景）
数组类参数（如 brands[]=a&brands[]=b）必须用 append()，set() 会把整个数组压成单个字符串，后端通常收不到预期结构。
同步到地址栏不刷新页面的关键三步
仅改 url.href 不会影响浏览器地址栏；必须配合 history.replaceState()。
- 先提取当前参数：
const params = new URLSearchParams(location.search) - 再修改：
params.set("offset", "40") - 最后写回：
history.replaceState(null, "", `?${params}` + (location.hash || ""))
漏掉 location.hash 会导致锚点丢失；用 location.href = ... 会强制跳转并重置滚动位置；replaceState 第三个参数是**完整路径**（含 ?），不是纯 query 字符串。
IE11 兼容性问题没法绕开
URL 和 URLSearchParams 在 IE11 中完全不可用，polyfill（如 url-search-params-polyfill）只能补 URLSearchParams 构造函数，但无法修复 new URL().searchParams 的缺失 —— 因为 IE 根本没有 URL 构造函数。
- 现代项目：直接用，加 Babel + core-js 也救不了 IE 的
URL缺失 - 需兼容 IE：降级方案只能是手动拼接 +
encodeURIComponent，且必须对每个 value 单独编码 - 服务端渲染（SSR）场景：Node.js 环境下可用
new URL(req.url).searchParams（Node ≥ 10.0），别依赖客户端 API 解析初始参数
最容易被忽略的是编码一致性：URLSearchParams 内部自动编码，而手动拼接时漏掉 encodeURIComponent，遇到空格或中文就直接让整个请求 400 —— 这类错误在线上环境极难复现，但一出就是线上事故。
