uri含中文导致404的根源是浏览器将未编码的中文、空格、&、=当作url分隔符截断路径，如src="js/app.js?name=张三"中“张三”后参数丢失；需对每个查询参数值单独调用encodeuricomponent()编码，而非编码整个url字符串。
URI中含中文导致资源404的根源
浏览器把未编码的中文、空格、&、= 当作 URL 分隔符直接截断路径——比如 src="js/app.js?name=张三" 会被解析成 js/app.js?name=张三（张三 后面若还有参数，全丢了），服务器收不到完整请求，自然返回 404。
常见于动态拼接 <script></script> 或 <link> 的 src/href 时，直接拼接用户输入或变量，没调用 encodeURIComponent()。
检查方式：打开浏览器 Network 面板，看失败请求的 Request URL 是否含未编码中文、空格，或出现不完整 % 编码（如只有 %E4 没后续字节）；服务端日志若显示路径被截断（如只收到 /static/css/main.css?theme=dark，但前端本意是传 ?theme=dark&v=2），基本就是 & 没编码。
前端拼接中文参数的正确写法
对每个查询参数值单独编码，不是对整个 URL 字符串编码：
src="data.js?name=" + encodeURIComponent(name) + "&id=" + encodeURIComponent(id)- 避免
encodeURIComponent("data.js?name=张三")—— 这会把?和=也编码，变成无效 URL - 如果用模板字符串，同样要逐字段编码：
src=`data.js?name=${encodeURIComponent(name)}&id=${encodeURIComponent(id)}`
服务端接收时无需额外解码（主流框架如 Express、Spring Boot 默认自动 decode），但若手动解析 query string，需注意使用对应语言的 URL 解码函数（如 Node.js 的 decodeURIComponent()）。
静态 HTML 中引用含中文路径的资源怎么办
HTML 文件本身路径含中文（如 /页面/about.html）在多数现代服务器上已支持，但风险高、兼容性差，不建议生产环境使用。更常见且危险的是：资源路径里带中文，比如 <img src="%E4%BA%A7%E5%93%81%E5%9B%BE/%E6%96%B0%E6%AC%BE.jpg">。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
这类路径在以下场景极易 404：
- 部署到 Nginx/Apache 时未启用 UTF-8 路径支持（Nginx 需
charset utf-8;） - Tomcat 默认禁用非 ASCII URI（需在
server.xml的Connector加URIEncoding="UTF-8"） - file:// 协议下，Chrome 等浏览器直接拦截含中文的资源请求
最稳妥做法：资源文件名一律用英文+数字+短横线，路径层级也避免中文。实在无法控制来源（如用户上传文件名含中文），后端应重命名存储，并返回标准化路径给前端。
为什么不能靠 meta refresh 或 JS 跳转来“修复”404
有人试图在返回 404 的 HTML 里加 <meta http-equiv="refresh" content="0;url=/home"> 或用 location.href 跳转，这会导致两个严重问题：
- HTTP 响应状态码仍是 404，但页面瞬间跳走，用户看不到错误提示，也无从修正 URL
- 搜索引擎抓取时拿到的是 404 页面内容，但因跳转逻辑存在，可能误判为临时重定向（实际未发 302），或干脆忽略该 URL，影响死链回收和 SEO
真正需要的是：让 404 页面本身可访问、可渲染、可操作——内联样式、禁用外部请求、提供搜索框或主页链接。跳转只能是用户主动行为（比如点“返回首页”按钮），而不是自动触发。
中文路径的问题本质是 URI 编码与服务器配置的协同问题，不是前端单方面能兜底的。最容易被忽略的一点是：即使你写了完美的 encodeURIComponent，若后端 Tomcat 没设 URIEncoding="UTF-8"，请求进来时就已经被截断或乱码了——此时前端再怎么编码也没用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
