核心是路径被负载均衡器重写导致不匹配，需对齐浏览器请求url、中间层重写规则与后端接收路径，并校准publicpath、修正proxy_pass斜杠、加try_files兜底。
负载均衡后静态资源加载 404，核心不是文件丢了，而是请求路径在转发过程中被改写、截断或补前缀，导致后端服务收到的 URL 和真实资源位置不匹配。排查要从“浏览器发了什么”“中间层改了什么”“后端收到了什么”三层对齐入手。
看浏览器实际发出的请求路径
打开开发者工具 → Network → 刷新页面 → 筛选 css 或 js → 找到 404 请求，点开看它的 Request URL（比如 /app-a/css/main.abc.css）。这个 URL 就是浏览器真正发出的地址，也是后续所有环节的起点。注意是否带了额外前缀（如 /prod/app-a/）、是否少了子路径、是否大小写异常。
查负载均衡器的路径重写规则
常见问题包括：Nginx 的 proxy_pass 末尾多加了斜杠、rewrite 规则误删路径段、K8s Ingress 的 path 配置未启用 stripPrefix。重点核对以下三点：
- Nginx 中
location /app-a/ { proxy_pass http://backend/; }—— 末尾的/会把/app-a/css/变成/css/转发 - 若前端构建时设了
publicPath: "/app-a/"，但 Nginx 没做对应前缀透传，资源就会去错地方 - 多级代理（如 CDN → LB → Nginx → 应用）中，某一层漏配
try_files $uri /index.html;或未开启路径透传
确认后端服务是否能按原始路径响应
绕过负载均衡，直接 curl 后端服务的 IP 和端口，用浏览器里看到的那个完整 URL 测试（例如 curl http://10.0.1.5:8000/app-a/css/main.abc.css）。如果返回 200，说明后端本身没问题；如果也 404，说明后端静态资源映射配置没覆盖该路径，需检查框架的静态资源根目录、static 目录位置、或是否启用了路径前缀拦截（如 Spring Boot 的 spring.web.resources.static-path-pattern）。
验证 publicPath 与部署路径是否一致
前端打包产物中的资源引用路径，由构建工具（Webpack/Vite）的 publicPath 决定。它必须和负载均衡最终暴露给用户的 URL 前缀完全一致。例如：
- 用户访问
https://example.com/app-a/，则publicPath应设为/app-a/ - 若设成
/，所有资源会请求/css/xxx.css，但 LB 并未将该路径转发到后端 - Vite 项目还需检查
base配置，Webpack 则看output.publicPath
