本质是请求路径未变但服务端资源映射或文件位置变更，导致“路还在、门牌号对不上”；需先验证流量是否真实抵达新节点，再比对新旧环境静态路径配置、文件实际存在性、cdn及中间层缓存策略。
流量切换后静态资源 404，本质是请求路径没变，但服务端资源映射或文件位置变了。不是代码崩了，而是“路还在，门牌号对不上”。
确认流量是否真切到新节点
别急着改配置，先验证流量是否真的走了新服务：
- 在新旧节点分别加临时日志或响应头（如 X-Node: old / X-Node: new），用 curl 或浏览器 Network 面板看实际返回的 header
- 检查负载均衡器（Nginx、SLB、ALB 等）的后端健康检查状态和权重分配，确认新节点已上线且流量已分发
- 如果用了灰度或 AB 测试，确认路由规则（如 cookie、header、IP 段）没意外匹配到错误集群
比对新旧环境的静态资源路径逻辑
404 往往出现在“路径看起来一样，实际解析不同”：
- 检查 STATIC_URL（Django）、spring.mvc.static-path-pattern（Spring Boot）、或 Nginx 的 location /static/ 配置——新环境是否漏配、多斜杠、大小写不一致（如
/Static/vs/static/） - 确认新节点上静态文件真实存在：SSH 登录，执行
ls -l /path/to/static/img/logo.png，注意路径是否被构建脚本覆盖、是否遗漏collectstatic或mvn clean package - 对比新旧节点的 document root（Nginx/Apache）或 webapp 目录结构，常见坑：新包里 static 文件夹被误删、构建时未启用 public 目录拷贝、Docker volume 挂载路径错位
抓取失败请求的真实 URL 并反向追踪
浏览器 Network 面板里点开那个 404 请求，重点看三项：
-
Request URL：复制完整地址（如
https://example.com/static/css/app.css?v=2），手动在新节点 curl 测试：curl -I https://new-node-ip/static/css/app.css - Referrer：确认来源页面路径，判断是否因 base 标签、SPA 路由或相对路径导致路径计算偏移
- Response Headers 中的 Server / X-Powered-By：验证是否真的打到了新服务，还是被缓存、CDN 或反向代理中途劫持
检查 CDN 和中间层是否缓存了旧路径或拦截了新规则
流量切了，但 CDN 可能还在吐旧响应：
- 在请求头中加 Cache-Control: no-cache 或用无痕模式访问，排除 CDN 缓存干扰
- 查看 CDN 后台：是否有针对
/static/*的缓存策略、是否配置了错误的回源 host 或路径重写规则 - 检查是否启用了边缘函数、WAF 或安全网关，它们可能按旧规则拦截了带新版本参数（如
?v=2）的请求
