根本原因是中文字符未用 encodeURIComponent() 编码，导致浏览器解析异常、服务端解码错乱或中间环节丢弃字符；必须前端编码、后端统一 UTF-8 解码，避免重复编解码。
URL 中中文参数被浏览器截断或显示为乱码
根本原因是中文字符未经过 encodeURIComponent() 编码，直接拼入 URL 路径或查询参数中。浏览器会按当前页面编码（如 UTF-8）尝试解析，但服务端若未统一解码逻辑，或中间代理/重定向环节丢弃非 ASCII 字符，就会出现乱码、400 错误或参数为空。
- 仅用
encodeURI()不够——它不编码/、?、=等分隔符，适合整个 URL；但对单个参数值，必须用encodeURIComponent() - 后端接收时，node.js 的
url.parse()或 express 的req.query通常自动解码；php 需确认mb_internal_encoding('UTF-8')且未重复urldecode() - 避免手动拼接：
location.href = '/search?q=' + keyword→ 改为location.href = '/search?q=' + encodeURIComponent(keyword)
vue/react 等框架中路由跳转含中文参数仍乱码
框架的路由库（如 Vue router、React Router）内部虽调用 encodeURIComponent，但仅对 params 或 query 对象的值做处理，若你在 to 字符串中硬编码中文（如 to="/user/张三"），则不会被编码。
- Vue Router：用命名路由 +
params，而非路径字符串：{ name: 'user', params: { id: '张三' } } - React Router v6：使用
useNavigate()并传对象：navigate({ pathname: '/user', search: `?name=${encodeURIComponent('李四')}` }) - 若必须用 path 字符串，请确保路径段已编码：
/user/%E5%BC%A0%E4%B8%89，而非/user/张三
服务端收到的中文参数是 %E4%B8%AD%E6%96%87 但显示成 “涓?枃”
这是典型的 UTF-8 字节被当 GBK 解码的结果。说明服务端读取原始查询字符串后，错误地以非 UTF-8 编码重新解释了已解码的字符串。
- java servlet：检查是否显式调用了
request.setCharacterEncoding("GBK")，应删掉或统一设为"UTF-8" - Node.js：确保
req.url或req.query未被二次Buffer.toString('gbk')转换 - nginx：确认无
charset GBK;指令干扰响应头，且location块未启用rewrite导致原始 query 丢失
微信内置浏览器或旧版 ios safari 打开含中文的 a 标签跳转失败
部分 webview 对未编码的中文 URL 兼容性极差，点击后可能白屏、跳转到空页，或触发 Navigation cancelled。
立即学习“前端免费学习笔记（深入）”；
- 永远不要写
链接，必须编码：链接 - 动态生成时，用 JS 注册 click 事件并调用
Event.preventDefault(); location.href = ...，确保编码时机可控 - 测试时打开 chrome DevTools → Network → 查看实际发出的 Request URL，确认中文已转为 %xx 形式
真正容易被忽略的是：**前端编码和服务端解码必须在同一个字符集层级完成，且不能跨层重复编/解码**。比如前端用 encodeURIComponent（输出 UTF-8 byte 序列的百分号编码），后端就该直接按 UTF-8 解析，而不是先用 ISO-8859-1 读字节再转 UTF-8。