css加载失败主因是alias路径末尾斜杠不匹配：location /static/必须配alias /var/www/assets/，否则发生路径粘连导致404；还需排查正则location干扰、权限不足及配置未生效等问题。
样式表（CSS）加载失败，通常不是文件本身丢了，而是 Nginx 没有把请求正确映射到磁盘上的 CSS 文件路径。用 alias 配置虚拟目录时，这类问题高频出现，核心在于路径拼接逻辑被误解，或被其它 location 规则意外覆盖。
检查 alias 路径末尾斜杠是否匹配
alias 后的路径必须以 / 结尾（除非它指向单个具体文件），否则 Nginx 会把 location 匹配部分“粘”在 alias 路径末尾，造成错位。
- 错误写法：
location /static { alias /var/www/assets; }→ 请求/static/css/app.css实际查找/var/www/assetss/css/app.css（assets和css被连在一起） - 正确写法：
location /static/ { alias /var/www/assets/; }→ 请求/static/css/app.css正确映射到/var/www/assets/css/app.css - 注意：
location的匹配路径（如/static/）和alias路径（如/var/www/assets/）末尾斜杠必须一致
排查正则 location 是否干扰 alias
如果配置中存在类似 location ~ \.(js|css|png)$ 这类正则规则，且它出现在 alias 块之前，Nginx 会优先匹配正则并执行其中的 root 或其它指令，从而覆盖你为 /static/ 设置的 alias。
- 查看 error.log，确认 404 错误实际访问的是哪个物理路径 —— 很可能显示的是 root 下的路径，而非 alias 指向的路径
- 把正则 location 块移到 alias 块之后，或明确限定其作用范围（例如加前缀
^~或限制 URI 前缀） - 若必须用正则匹配静态资源，建议改用
root+ 精确 location，避免与 alias 冲突
验证权限、大小写与配置生效状态
路径对了，不代表就能读取；配置改了，不代表已加载。
- 确保 nginx 工作用户（如
www-data或nginx）对 alias 目录及其所有父目录有 执行（x）和读取（r）权限 - Linux 下严格区分大小写：URL 中是
/Static/，但 location 写成/static/或 alias 指向/Var/WWW/Assets/，都会 404 - 运行
nginx -t检查语法，再用nginx -T输出当前实际生效的完整配置，确认你修改的 server 块确实被加载 - 修改后需 reload（
nginx -s reload）或重启，避免旧进程仍在运行
快速定位真实路径的小技巧
别靠猜，让 Nginx 自己告诉你它想找哪儿。
- 在对应 location 块里临时加一句：
return 200 "real path: $request_filename"; - 用 curl 请求该 CSS 地址，直接看到 Nginx 解析出的完整磁盘路径
- 对比该路径与你期望的路径，差在哪一环，就修哪一环
