HTML怎么做Manifest查看_HTML DevTools Manifest信息查看【建议收藏】

怎么确认页面是否还在用AppCache（而非Service Worker）

AppCache（即通过manifest属性实现的缓存）和现代的Service Worker缓存机制是两套完全不同的东西，而且它们无法友好共存。如果你的页面不小心同时涉及两者，Service Worker甚至可能会被压制。那么，如何排查一个页面是否还在依赖已经失效的AppCache呢？可以重点看下面几个地方：

• 检查Cache Storage分类：打开DevTools → Application → Cache Storage。重点看左侧列表的分类名称。如果存在一个独立的AppCache分类（注意，不是Cache Storage下的某个缓存名），这就说明这个浏览器曾经为这个页面激活过AppCache机制，并且可能还保留着旧的缓存文件。
• 检查页面源代码：在Elements面板里，仔细查看标签。如果上面还有manifest="..."这个属性，那这就是一个明确的“遗产”标志，也是潜在的离线功能风险点。
• 进行离线测试：最简单粗暴的方法，就是断开网络，然后刷新页面。如果页面直接白屏，或者显示“无法连接到互联网”之类的错误，而你的本意是希望它离线可用，那么大概率就是你错误地相信了manifest属性，而没有正确配置Service Worker。

想看离线能力真实状态，该盯哪儿

既然旧的manifest属性之路已经堵死，那么构建可靠离线能力的唯一有效方案，就是Service Worker。它的状态可不能靠猜，必须去专门的面板里确认。

这里有一份实用的检查清单：

• Service Workers面板：打开DevTools → Application → Service Workers。这里你需要确认：是否有成功注册的Service Worker脚本文件？它的状态是否是activated？是否勾选了“Update on reload”以便于调试？
• Cache Storage面板：同样在Application下，查看Cache Storage。展开后，你应该能看到自己在Service Worker代码中定义的具体缓存名称（例如my-site-v1），而不是那个已经成为历史的AppCache。
• 网络请求状态：切换到Network面板，过滤service-worker.js。确保这个文件的请求状态码是200，并且响应头里包含正确的Content-Type: application/ja vascript。
• 控制台快速查询：在Console标签页里输入na vigator.serviceWorker.controller并回车。如果返回的是一个Service Worker对象，说明当前页面正被Service Worker控制；如果返回null，则说明Service Worker尚未取得控制权，离线功能可能未生效。

话说回来，现在真正棘手的，是那些年代稍久远或者存在误解的项目。开发者可能还停留在“给HTML加个manifest就是PWA”的旧观念里，导致HTML标签上挂着失效的manifest属性，但真正的Service Worker却没有注册，甚至因为网站没有部署HTTPS，连na vigator.serviceWorker这个API都不可用。在这种情况下，开发者再怎么修改.manifest文件都是徒劳，而DevTools里的Manifest标签页，也将永远是一片空白。这才是需要彻底扭转思路的关键所在。