HTML5更新需覆盖文件并穿透多层缓存。关键步骤：禁用HTML强缓存（设Cache-Control: no-cache），资源文件用哈希命名+长缓存，HTML最后上传，验证响应头、状态码及资源URL，同时清理CDN、更新preload/prefetch标签、触发Service Worker跳过等待。
HTML5 源码发布后怎么更新？直接覆盖就行，但得避开缓存坑
上线后的 HTML5 页面更新，本质是替换服务器上的静态文件，但用户浏览器可能还在用旧缓存。所以“改完就传上去”不等于“用户立刻看到新版本”，关键在控制缓存行为和验证生效路径。
为什么刷新页面还是旧版？重点查 Cache-Control 和 ETag
常见现象：上传了新的 index.html，但用户硬刷（Ctrl+F5）仍看到旧内容，甚至清本地缓存也无效——问题往往出在服务端响应头。
-
Cache-Control: public, max-age=31536000这类强缓存策略会让浏览器一年内都不重新请求 HTML 文件 -
ETag或Last-Modified未随文件变更而更新，导致协商缓存始终返回304 Not Modified - Nginx/Apache 默认对
.html启用较长时间缓存，需显式覆盖
实操建议：对 HTML 文件禁用强缓存，设为 Cache-Control: no-cache 或 max-age=0；资源文件（JS/CSS/图片）可用哈希命名 + 长缓存，靠文件名变化触发更新。
在线更新的三步操作流程（含验证动作）
不是上传完就结束，必须闭环验证。以下为最小可行流程：
立即学习“前端免费学习笔记（深入）”；
- 修改源码后，构建生成新文件（如 Webpack 输出带 hash 的
main.a1b2c3.js） - 通过
rsync、scp或 CI 脚本将新文件推送到生产服务器对应路径，**确保 HTML 文件最后上传**（避免中间状态出现 JS 文件已更新但 HTML 仍引用旧名） - 立即验证：
– 在隐身窗口访问页面，禁用缓存（DevTools → Network → ✅ Disable cache）
– 查看Network面板中index.html的响应头是否为200且Cache-Control符合预期
– 检查 JS/CSS 文件 URL 是否含新 hash，控制台无 404
容易被忽略的细节：CDN、预加载、Service Worker
这些机制会放大缓存问题，且失效逻辑各自独立：
- 用了 CDN（如 Cloudflare、阿里云 CDN）？上传后必须主动
Purge Cache，不能只等 TTL 过期 - HTML 中有
<link rel="preload">或<link rel="prefetch">？它们也会被缓存，URL 变更后需同步更新标签 - 项目注册了
Service Worker？它有自己的缓存策略，index.html更新后必须触发skipWaiting()+clients.claim()，否则旧 SW 会持续拦截请求并返回缓存页
更新 HTML5 应用最麻烦的从来不是传文件，而是确认所有缓存层都已穿透——浏览器、CDN、反向代理、Service Worker，少一个，用户就卡在旧版本里。
