中文路径报404的根本原因是uri编码与服务端解码不匹配：浏览器发送未编码、半编码或双重编码路径，nginx默认不解码，导致无法映射到utf-8文件名；css中url()需手动percent-encode，js动态设置必须用encodeuricomponent，生产环境应禁用中文路径。
中文路径报404，根本不是“浏览器不支持中文”，而是 URI 编码和服务器解码没对齐——写 images/产品图.jpg 看似没问题，但请求发出去的可能是未编码、半编码或过度编码的字符串，服务端一查路径不存在，就直接返回 404。
background-image 中的中文路径为什么总 404
CSS 的 url() 是纯 URI 上下文，RFC 3986 要求非 ASCII 字符必须 percent-encode。现代浏览器（Chrome/Firefox/Edge）对 HTML 属性值会自动编码，但对 CSS 里的 url() 行为不一致：Safari 某些版本会原样发送中文，Nginx 默认不 decode，结果就是 /images/产品图.jpg → 404。
- 别直接写
background-image: url("images/产品图.jpg");，改用background-image: url("images/%E4%BA%A7%E5%93%81%E5%9B%BE.jpg"); - JS 动态设置时必须手动 encode：
el.style.backgroundImage = `url(images/${encodeURIComponent('产品图.jpg')})`; - 如果用 Webpack/Vite 构建，确保 asset 处理插件（如
asset类型资源）已启用，并检查输出文件名是否被自动转义或重命名
img src 和 a href 里写中文真能行吗
<img src="images/%E4%BA%A7%E5%93%81%E5%9B%BE.jpg"> 这类写法在多数浏览器中“看起来”能加载，是因为 HTML 解析器会对属性值做一次自动 URI 编码，再发请求。但这只是表象，隐患仍在：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 服务端响应头
Content-Type若缺失或错误（比如返回text/plain），浏览器可能拒载 - CDN 或反向代理（如 Cloudflare）可能丢弃或误处理编码后的路径
- Linux 文件系统虽支持 UTF-8 文件名，但 Nginx 默认不调用
utf8模块解码路径，/images/%E4%BA%A7%E5%93%81%E5%9B%BE.jpg就匹配不到磁盘上真实文件 - 验证方法：用
curl -I "http://localhost/images/产品图.jpg"，看返回状态码和Content-Type；再对比curl -I "http://localhost/images/%E4%BA%A7%E5%93%81%E5%9B%BE.jpg"
Nginx 怎么让中文路径真正生效
光靠前端编码不够，服务端必须正确 decode 并映射到文件系统。Nginx 默认不开启 URI 解码，需手动干预：
- 确认 Nginx 编译时启用了
--with-http_charset_module（主流发行版通常默认包含） - 在
location块中显式声明编码：charset utf-8;，并加一行rewrite ^/(.*)$ /$1 break;（触发内部重写，促使解码） - 更稳妥的做法是：禁用中文路径，构建时用脚本批量重命名资源为 ASCII（如
chanpin-tu.jpg），并在 HTML/CSS/JS 中统一引用新名 - 若必须保留中文，建议只用于后端 API 返回的动态路径（由服务端控制 encode/decode），静态资源一律规避
最常被忽略的一点：本地双击打开 file:/// 页面时出现的“404”，其实是浏览器安全策略拦截，和 URI 编码完全无关。这种场景下，连 HTTP 协议都没走，压根不会触发服务器解码逻辑——要真测中文路径，必须起 HTTP 服务，且全程盯紧 Network 面板里的 Request URL 和 Response Headers。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
