css在docker中404主因是前端构建路径（如url(../fonts/icon.woff)）与容器内真实文件结构不匹配，须同步调整vite/webpack的base或publicpath配置、nginx的location+root规则，三者严格对齐方可解决。
CSS在Docker里404，90%不是Nginx没配好，而是构建时路径和容器内文件结构对不上——必须从前端打包配置和Nginx两头改，缺一不可。
为什么CSS里的url(../fonts/icon.woff)进容器就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根目录下根本没这个路径。
验证方法：
- 用
grep -r "url(" dist/css/看构建产物里是否还满屏../ - 用
ls -R dist/ | head -20确认fonts/是否和css/同级 - 浏览器Network面板点开404的font请求，看Request URL是不是以
/fonts/开头（说明前端没加base前缀）
Vite或Webpack必须设base或publicPath为绝对前缀
相对路径靠不住，所有资源URL得从构建阶段就带明确前缀，且值必须和Nginx的location规则对齐。
- Vite用户：在
vite.config.ts里写base: '/static/'，这样生成的<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更直观可靠。
- 正确写法：
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 "</nginx-container>，确认是404还是403（后者可能是权限问题） - 用
docker exec -it <container> ls -l /usr/share/nginx/html/static/</container>直连容器验证物理路径是否存在
最常被忽略的是三者没对齐：前端base设了/static/，但Nginx没配location ^~ /static/，或者配了却用alias写错路径，又或者构建产物里压根没生成static/子目录——任一环节断掉，CSS里的资源就全挂。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
