大型SPA滚动更新时静态资源404是确定性问题，源于构建产物无内容哈希、Ingress未平滑过渡、前端不支持多版本共存；需启用contenthash、按版本目录部署、Nginx fallback配置及前端容错降级，并通过滚动模拟与监控闭环验证。
大型SPA应用在Kubernetes集群中滚动更新时，常出现短暂但高频的静态资源404——比如CSS、JS文件加载失败，页面白屏或样式错乱。这不是偶发网络抖动，而是更新过程中新旧Pod交替、浏览器缓存与服务端资源版本不一致、以及Nginx路由未对齐导致的**确定性问题**。核心在于：构建产物未做内容哈希隔离、Ingress未实现平滑过渡、前端未适配多版本共存场景。
确保构建产物带内容哈希且独立可寻址
Vue/React等框架默认生成带hash的文件名（如app.a1b2c3.js），但必须确认以下三点：
- Webpack/Vite配置中
filename和chunkFilename启用[contenthash]，而非[hash]或[name] -
index.html由构建工具自动生成并注入正确路径，禁止手动写死或用CDN绝对路径覆盖相对引用 - 所有静态资源（含
public/下文件）均通过构建流程纳入hash管理；若需保留public/内资源，应统一加版本前缀（如/v1.2.3/logo.png）并配合Nginx重写
配置Nginx Ingress支持多版本资源共存与回退
滚动更新期间，旧Pod可能仍在服务老版本index.html，而新Pod返回新版本JS——但浏览器按旧HTML中的路径去请求新资源，路径已变，直接404。解决方式是让Nginx能“认出”不同版本资源并兜底：
- 在Ingress annotation中启用
nginx.ingress.kubernetes.io/configuration-snippet，添加try_files $uri /index.html =404;仅适用于根路径；更稳妥的是按版本号匹配 - 将构建输出目录结构改为
/dist/v${VERSION}/（如/dist/v1.5.2/），并在index.html中使用相对路径（./js/app.xzy789.js）或动态base（通过环境变量注入<base href="/v1.5.2/">） - Nginx配置中增加location块，对
/v\d+\.\d+\.\d+/路径做显式root映射，并对不存在的子路径统一fallback到对应版本的index.html，避免跨版本混用
前端增加资源加载容错与降级机制
即使服务端做了保障，浏览器仍可能因缓存、CDN中间层或并发请求竞争拿到不匹配的资源。可在入口JS中主动拦截异常：
- 监听
window.addEventListener('error', ...)捕获script/link加载失败，对关键资源（如main.js、vendor.css）触发自动重试或提示用户刷新 - 利用
import()动态导入时包裹try/catch，失败后延迟重试或加载备用CDN地址 - 在
index.html头部插入轻量脚本：检查document.currentScript.src是否包含预期版本号，若不匹配则强制跳转到当前版本的完整URL（如location.replace('/v1.5.2/')）
验证与观测闭环不可少
上线前必须模拟滚动更新过程验证，不能只测单Pod：
- 用
kubectl scale deploy/my-spa --replicas=3扩至3副本，再执行set image触发滚动更新，同时用curl轮询/v1.5.1/index.html和/v1.5.1/js/app.xxx.js，确认旧路径仍可访问 - 在Prometheus中采集Nginx的
upstream_status和request_uri，对返回404但URI含/v\d+\.\d+\.\d+/的请求打标告警 - 前端Sentry上报
ResourceLoadError事件，附带document.baseURI和performance.getEntriesByType('resource')中各资源HTTP状态码，定位是服务端缺失还是客户端缓存污染
