本质是HTML与JS/CSS资源版本不同步导致的404，根源在构建、部署、缓存协同失配；需通过原子发布、哈希校验、客户端容错及服务端精准fallback来解决。
大型 SPA 应用在轮询更新期间出现静态资源 404，本质不是路由问题，而是资源版本失效与缓存策略冲突导致的“旧 HTML 引用新哈希资源失败”现象。它常被误判为服务器配置问题，实则发生在构建、部署、缓存协同环节。
一、问题根源：HTML 与 JS/CSS 资源不同步
当应用启用自动轮询更新（如通过 window.location.reload()、location.replace() 或 PWA 的 skipWaiting() 触发），浏览器会重新请求 index.html。若此时：
- 新版
index.html已上线（含新哈希的<script src="app.a1b2c3.js">） - 但旧版 JS/CSS 文件尚未完成全量同步（CDN 边缘节点未刷新、OSS 上传中断、灰度发布不一致）
- 或用户本地强缓存了旧版
index.html，却尝试加载新版资源路径
→ 浏览器请求 app.a1b2c3.js，而该文件在服务端不存在 → 返回 404。
常见触发场景：
- CI/CD 构建后仅推送 HTML，JS/CSS 延迟数秒上传
- 使用 CDN 时，HTML 缓存 TTL 过长（如 1 小时），而资源文件缓存 TTL 更短（如 10 分钟）
- 多实例部署中，负载均衡后部分节点仍运行旧静态资源目录
二、关键防御措施：确保 HTML 与资源原子性一致
✅ 构建阶段：生成稳定、可验证的资源映射
- 不依赖
html-webpack-plugin默认注入，改用--stats-json+ 自定义模板，确保index.html中引用的资源名与实际产出文件严格一一对应 - 输出
asset-manifest.json（含所有资源哈希与路径），供后续校验或服务端动态注入使用 - 启用
output.assetModuleFilename: '[hash][ext]'统一资源命名逻辑，避免 CSS/JS/图片哈希规则不一致
✅ 部署阶段：强制资源与 HTML 同步发布
-
禁止分步上传：HTML 和所有
dist/下资源必须作为单次原子操作上传（如 tar 包解压、rsync--delete-after、或对象存储的多文件事务上传） - 若用 CDN，上传后立即调用其 API 刷新 HTML 路径（如
/index.html），不要刷新整个域名或通配符（避免误刷掉正在使用的旧资源） - 对于灰度发布，确保同一灰度批次内：HTML 版本号、资源哈希、CDN 缓存 Key 三者绑定（例如
Cache-Key: v2.3.1+sha256:a1b2...）
✅ 运行阶段：客户端容错与优雅降级
- 在
index.html中加入轻量校验脚本，检测关键资源是否可访问：<script> const assets = ['app.a1b2c3.js', 'chunk.v4d5e6.css']; const failed = []; assets.forEach(src => { const link = document.createElement('link'); link.rel = 'preload'; link.as = src.endsWith('.css') ? 'style' : 'script'; link.href = src; link.onerror = () => failed.push(src); document.head.appendChild(link); }); if (failed.length) { // 触发软重载或提示用户刷新 localStorage.setItem('spa-needs-refresh', 'true'); } </script> - 配合 Service Worker，在
fetch事件中拦截资源请求，对 404 的哈希资源自动回退到上一版本（需预存历史资源清单）
三、服务端辅助：避免“假 404”干扰诊断
- Nginx / Apache 配置中，不要对
.js/.css路径做无差别try_files $uri /index.html（这会掩盖真实缺失问题，且污染前端错误监控） - 正确做法：仅对
location /做 SPA fallback；对静态资源路径（如/static/,/assets/）启用严格try_files $uri =404，确保缺失即报错，便于快速定位上传遗漏 - 开启
log_format记录$request_uri与$status，配合日志告警：连续 5 次同哈希资源返回 404 → 触发部署完整性检查
不复杂但容易忽略
