URLSearchParams构造函数可传字符串、对象或迭代器初始化，但字符串须为合法查询字符串（不含?前缀）；set()覆盖同名键，append()追加，get()仅返首值，getAll()返数组；始终用toString()获取编码后字符串。
URLSearchParams 构造函数怎么用
直接传入字符串或对象就能初始化，但要注意字符串必须是合法的查询字符串格式（?key=value&foo=bar），不能带 ? 前缀，否则会把整个字符串当做一个键名处理。
常见错误：从 window.location.search 拿到的值自带 ?，直接传进去会导致解析失败：
// ❌ 错误写法
new URLSearchParams(window.location.search) // 结果：{ "?key": "value" }
// ✅ 正确写法
new URLSearchParams(window.location.search.slice(1))
// 或更稳妥地
new URLSearchParams(new URL(window.location.href).searchParams)
- 支持传入
URLSearchParams实例、Record对象、Iterable（如数组） - 对象方式会自动调用
toString()，所以不要传数字或布尔值——{ count: 42 }会被转成"42"，但{ active: true }变成"true"，可能不符合后端预期 - IE 不支持，需用
url-search-params-polyfill或自行封装降级逻辑
如何安全地增删改查参数
set()、append()、get()、delete() 是最常用方法，但行为差异明显，容易混淆：
-
set(key, value)：覆盖所有同名键 → 适合“唯一参数”场景（如page、sort） -
append(key, value)：追加新键值对 → 适合多选过滤（如category=1&category=2） -
get(key)只返回第一个匹配值；getAll(key)返回数组 —— 如果后端允许重复 key，务必用getAll，否则漏数据 -
has(key)判定存在性比get(key) !== null更可靠，因为值可能是空字符串
示例：更新当前 URL 的 q 参数并保留其余参数
const params = new URLSearchParams(window.location.search.slice(1));
params.set('q', 'react router');
history.replaceState(null, '', `${location.pathname}?${params}`);
序列化结果为什么有时不编码，有时又乱码
toString() 输出的是已编码的字符串（空格→%20，中文→%E4%B8%AD），但如果你手动拼接或用 JSON.stringify 处理，就可能跳过编码步骤，导致服务端解析失败。
- 永远用
params.toString()获取最终查询字符串，不要自己拼key + '=' + value - 如果值来自用户输入，
URLSearchParams会自动编码；但若你先用encodeURIComponent编码过一遍，再传给set()，就会双重编码（中文→%25E4%25B8%25AD） - 服务端接收时，PHP 的
$_GET、Node.js 的querystring.parse()默认解码，无需额外处理；但某些代理或 Nginx 配置可能提前解码一次，造成异常，这时要检查中间层行为
和原生 location.search 同步更新的坑
直接修改 URLSearchParams 实例不会影响浏览器地址栏，必须手动触发 pushState 或 replaceState。但有两点极易忽略：
- 调用
history.pushState后，window.location.search不会立即更新，下次读取仍为旧值 → 应该基于当前params实例操作，而非反复读location.search - 如果页面监听了
popstate，需确保在事件回调里也重新解析location.search，否则状态不同步 - 单页应用中，路由库（如 React Router v6）已接管 URL 解析，直接操作
URLSearchParams后还应调用其导航方法（如navigate），否则视图不响应
真正麻烦的不是语法，而是参数语义是否被前后端共同约定好——比如 limit=0 表示“不限制”，还是“非法值需忽略”？这类边界逻辑，URLSearchParams 一概不管。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
