最稳方案是避开中文路径，而非硬刚编码；应统一用英文+数字+短横线命名资源，构建时用脚本扫描非法文件名，必要时对小图标采用base64内联。
直接用 encodeURIComponent() 处理路径不靠谱
浏览器解析 CSS 中的 background-image: url(...) 时，不会自动对 URL 进行 JS 式的 URI 编码。哪怕你在 JS 里用 encodeURIComponent() 拼出路径再赋值给 style.backgroundImage，也容易因双重编码或未解码导致 404 —— 特别是路径含空格、括号、中文等字符时。
CSS 里写中文路径必须用 UTF-8 原样保留 + 服务端正确响应
现代浏览器（Chrome/Firefox/Edge/Safari）原生支持 CSS 中直接写 UTF-8 编码的中文路径，前提是：HTML 文件本身声明了 UTF-8 编码，且 Web 服务器返回的响应头 Content-Type 包含 ; charset=utf-8。
-
必须出现在最前面 - 检查响应头：用浏览器开发者工具 → Network → 刷页面 → 看 HTML 请求的
Content-Type是否为text/html; charset=utf-8 - CSS 中直接写：
body { background-image: url("images/背景图.jpg"); }（注意：引号可选，但建议加；路径中斜杠用正斜杠/）
Node.js / Python / Nginx 下中文路径 404 的真实原因
不是浏览器问题，而是服务端没正确处理 URI 解码。HTTP 协议要求路径部分（path segment）在传输时被 percent-encoded（如 %E4%B8%AD%E6%96%87.jpg），服务端收到后必须解码才能匹配文件系统中的真实中文名。
- Node.js（Express）：默认不自动解码路径，需用
decodeURIComponent()手动处理req.url，或改用express.static()（它内部已处理） - Python（Flask）：
send_from_directory()支持中文路径，但确保传入的是解码后的字符串，而非原始request.path - Nginx：确认配置中无
underscores_in_headers on类干扰项；静态文件服务下，只要文件系统编码与磁盘一致（Linux 一般 UTF-8，Windows 默认 GBK），且 Nginx 编译时启用了 UTF-8 支持，就可直读中文名
最稳方案：避开中文路径，而不是硬刚编码
开发阶段看着方便，上线后极易因环境差异（文件系统编码、CDN、代理层、CI 构建路径转换）出问题。真实项目中，所有资源路径统一用英文+数字+短横线：
立即学习“前端免费学习笔记（深入）”；
- 把
images/用户头像.jpg改成images/user-avatar.jpg - 构建脚本里加校验：
find . -name "*[一-龥]*" -o -name "*[^a-zA-Z0-9._/-]*"扫描非法文件名 - 若必须保留中文语义，可用
data:image/png;base64,...内联小图，但仅限图标类，避免阻塞渲染和缓存失效
路径里带中文不是“能不能”，而是“值不值得为它多花三小时排查 Nginx 日志或 Git for Windows 的 CRLF 转码问题”。
