必须用encodeuricomponent()编码url中文参数，因escape()已废弃且不兼容rfc 3986；拼接时仅编码值，推荐urlsearchparams；需前后端明确解码责任并排查代理重复解码。
URL编码必须用 encodeURIComponent()，不能用 escape()
浏览器地址栏里出现中文乱码，本质是 URL 中的中文没做标准编码。JavaScript 的 escape() 已废弃，它对部分字符（如中文、+、/）编码不兼容 RFC 3986，会导致服务端解析失败或解码成乱码。
正确做法是：所有要拼进 URL 查询参数的中文字符串，必须用 encodeURIComponent() 包裹。
-
encodeURIComponent("张三")→%E5%BC%A0%E4%B8%89（标准 UTF-8 编码） -
escape("张三")→%u5F20%u4E09（非标准 Unicode 转义，现代后端基本不认） - 拼接时只编码值，不要连
=或&一起编："?name=" + encodeURIComponent(val)，不是encodeURIComponent("?name=" + val)
后端接收前要确认解码逻辑是否自动触发
很多 Web 框架（如 Express、Spring Boot、Django）会在解析查询参数时自动调用 URL 解码，但前提是请求头 Content-Type 或传输编码没被干扰。常见踩坑点：
- Nginx 反向代理默认会“二次解码”一次，如果后端又解一次，中文就变乱码 —— 需在 Nginx 配置中加
underscores_in_headers on;并检查location块是否启用了proxy_redirect或多余rewrite - Java Servlet 中，
request.getParameter("name")默认按 ISO-8859-1 解码，若未提前设置request.setCharacterEncoding("UTF-8")，就会把%E5%BC%A0错解为乱码 - Node.js 的
url.parse(req.url, true).query.name是自动解码过的，但若原始 URL 被手动拼接过且重复编码（比如两次encodeURIComponent），就会解出乱码
跳转时避免直接拼字符串，优先用 URLSearchParams
手写 "?a=" + encodeURIComponent(x) + "&b=" + encodeURIComponent(y) 容易漏转义、错顺序、引号不匹配。现代浏览器支持 URLSearchParams，更安全、可读性高，还自带追加/删除/遍历能力。
const params = new URLSearchParams();
params.set("name", "张三");
params.set("city", "北京");
window.location.href = "/search?" + params.toString(); // 自动编码，结果：/search?name=%E5%BC%A0%E4%B8%89&city=%E5%8C%97%E4%BA%AC
-
params.toString()输出的是已编码的完整查询字符串，不用再套encodeURIComponent - IE 不支持
URLSearchParams，如需兼容，可用 polyfill 或降级为手动拼接 +encodeURIComponent - 注意：
URLSearchParams对空格编码为%20（符合标准），不是+，后端需能接受这种格式
调试时用浏览器开发者工具看真实发送的 URL
别只信你写的代码，要看 Network 面板里「实际发出的请求 URL」。重点检查：
- 地址栏显示的 URL 是否含中文？如果是，说明根本没编码 —— 跳转前没调
encodeURIComponent或URLSearchParams - Network 的 Headers → Request URL 字段里，中文是否变成
%xx%xx形式？如果不是，问题在前端拼接环节 - Response 返回的页面里，
document.location.search解析出来是否正常？可临时加console.log(new URLSearchParams(location.search))验证 - 后端日志打印原始 query string（而非
getParameter结果），确认收到的是%E5%BC%A0还是乱码字节，能快速定位解码发生在哪一层
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
