CSS在Docker容器中404，90%源于前端构建路径（如url(../fonts/icon.woff)）与容器内真实文件结构不匹配，必须同步调整Webpack/Vite的publicPath/base配置和Nginx的location+root规则，三者对齐才有效。
CSS在Docker容器里404，90%不是Nginx没配好，而是前端构建时生成的路径（比如url(../fonts/icon.woff)）和容器内真实文件结构不匹配——得从前端打包配置和Nginx两头改，缺一不可。
为什么url(../xxx)在容器里总404？
Webpack/Vite构建时按开发目录结构解析相对路径，但Docker镜像里COPY dist/ /usr/share/nginx/html/后，物理路径变成/usr/share/nginx/html/css/app.css + /usr/share/nginx/html/fonts/icon.woff，而CSS里写的url(../fonts/icon.woff)实际会请求/fonts/icon.woff，Nginx根目录下根本没有这个路径。
- 检查构建产物里的CSS内容：
grep -r "url(" dist/css/，看是不是还满屏../ - 确认
dist目录结构：ls -R dist/ | head -20，看fonts/是不是和css/同级 - 浏览器Network面板里点开404的font请求，看Request URL是不是以
/fonts/开头（说明前端没加base前缀）
publicPath或base必须设成/static/这类绝对前缀
相对路径靠不住，必须让所有资源URL从构建阶段就带明确前缀。Vite用base，Webpack用publicPath，值必须和Nginx的location规则对齐。
- Vite用户：在
vite.config.ts里写base: '/static/'，这样import './style.css'生成的link href就是/static/css/app.css - Webpack用户：在
vue.config.js或webpack.config.js里设publicPath: '/static/'，别设成./或空字符串，否则构建产物仍用相对路径，进容器就失效 - 确保
dist/里真有static/子目录——如果构建后是dist/css/直出，就得同步把publicPath设为/，并调整Nginx映射逻辑
Nginx的location ^~ /static/要配root，别用alias
alias容易少一层路径，root更直观可靠。假设你把整个dist/拷到/usr/share/nginx/html/，那么/static/对应的就是这个目录下的static/子目录。
立即学习“前端免费学习笔记（深入）”；
- 正确写法：
location ^~ /static/ { root /usr/share/nginx/html; }→ 请求/static/css/app.css映射到/usr/share/nginx/html/static/css/app.css - 错误写法：
location /static/ { alias /usr/share/nginx/html/static/; }→ 请求/static/css/app.css会去找/usr/share/nginx/html/css/app.css（少了一层static） - 如果用了
include /etc/nginx/conf.d/*.conf，确保你的静态规则文件名按字母序早于其他location /块（如命名为00-static.conf）
验证CSS引入的字体、图片真正在容器里可访问
别只刷页面看样式是否生效——浏览器开发者工具的Network标签页里，筛选Font或Img，点开每个404请求，看Request URL是不是你预期的路径；再对比Nginx日志：docker logs <nginx-container> | grep " 404 "，确认是404还是403（后者可能是权限问题）。
- 用
docker exec -it <container> ls -l /usr/share/nginx/html/static/直连容器验证物理路径是否存在且可读 - 如果CSS里用了
@import，注意它的解析起点是当前CSS文件所在目录，不是HTML——这在构建后容易暴露路径错位，建议优先用JS入口聚合样式 - 绝对路径
/static/xxx能规避相对路径跳转层级错误，但前提是publicPath、文件物理位置、Nginxroot三者严格对齐，漏掉任何一环都会404
