manifest失效后浏览器仍加载旧资源，因appcache锁定资源且不响应常规刷新；需彻底移除manifest属性、返回410、清除appcache（如chrome://appcache-internals/）并禁用其优先级。
manifest 文件失效后浏览器仍加载旧资源
HTML5 的 manifest 机制早已被主流浏览器弃用（Chrome 94+、Firefox 85+、Safari 未实现完整支持），但老项目若还残留 manifest，会导致页面强制走离线缓存，即使你删了文件、改了 HTML，用户打开的仍是旧版本。
根本原因不是“缓存没清”，而是浏览器把整个 manifest 关联的资源列表锁在了本地应用缓存（AppCache）里，这个缓存不响应常规刷新或 Ctrl+F5，也不受 Cache-Control 控制。
- 检查是否还在用：
—— 只要这行存在，且浏览器曾经成功解析过该app.manifest，就可能已激活 AppCache - 确认是否生效：打开 DevTools → Application → Cache Storage → 看有没有 “AppCache” 分类（不是 “Cache Storage”）
- 不要试图修改
manifest文件内容来触发更新——旧版浏览器对 hash 变更不敏感，新版浏览器直接忽略
手动清除 AppCache 的三种可靠方式
必须绕过浏览器 UI，直击底层缓存机制。开发者工具里的 “Clear site data” 通常不包含 AppCache（尤其 Chrome 90+ 后默认隐藏），得用更底层的操作。
- 地址栏输入
chrome://appcache-internals/（Chrome/Edge），找到对应站点，点 “Remove” —— 这是最直接的方式，但该页面已在 Chrome 94+ 被移除，仅适用于旧版 - 使用
window.applicationCache.swapCache()+window.applicationCache.update()组合触发重载（仅限仍支持 AppCache 的浏览器，且页面必须已加载过 manifest） - 终极方案：彻底移除
manifest属性 + 删除所有.manifest文件 + 在服务器端对原manifest路径返回404或410—— 浏览器下次访问时发现清单不可达，会自动废弃该缓存组
为什么 service worker 不能“覆盖”AppCache
Service Worker 和 AppCache 是两套互不兼容的离线机制，共存时浏览器优先启用 AppCache（如果已激活），哪怕你注册了 SW，fetch 事件也不会触发——资源直接从 AppCache 返回，SW 完全被绕过。
立即学习“前端免费学习笔记（深入）”；
- 现象：
navigator.serviceWorker.register()成功，但 Network 面板里所有请求都标着 “(from Application Cache)” - 验证方法：在控制台执行
window.applicationCache.status，返回值不是0（UNCACHED）就说明 AppCache 仍在生效 - 必须先清空 AppCache，再注册 SW，否则 SW 的 install/fetch 逻辑永远不会接管静态资源
服务器端配合：让旧 manifest 失效更快
光删前端代码不够，如果用户很久没访问，或者 DNS 缓存、CDN 缓存了旧 manifest 响应，浏览器仍可能重新拉取并激活它。
- 确保 Web 服务器对
.manifest路径返回明确的410 Gone（比404更能阻止重试），例如 Nginx 配置：location ~ \.manifest$ { return 410; } - 避免在
Content-Type响应头中设置text/cache-manifest—— 即使文件不存在，某些代理可能缓存错误响应头 - 如果用了 CDN，立即刷新
*.manifest相关路径，防止边缘节点返回陈旧的 200 响应
AppCache 的顽固性不在代码多难写，而在它像一个静默驻留的后台进程——看不见、不报错、不响应常规缓存策略。真正清理干净，靠的不是“清缓存按钮”，而是组合切断它的触发链、存储源和网络入口。
