DevTools Application 面板
Application 面板用于查看 Cookie、Storage、IndexedDB、Cache Storage、Service Worker 和 Manifest 等站点数据状态。
#concept
#growing
#frontend
#browser
#chrome-devtools
[!info] related notes
- 所属 MOC: 浏览器开发者工具 MOC, DevTools Application MOC, HTTP 与前端网络请求
- 前置概念: 浏览器客户端存储, Service Worker 与 Cache API, Cookie、Session、Token
- 并列概念: Network 面板, Security / Issues 面板
- 易混淆概念: 浏览器缓存体系
- 关系笔记: 浏览器开发者工具
DevTools Application 面板
一句话定义
Application 面板是查看“站点在浏览器本地留下了什么状态”的主入口。
核心内容
它最适合回答什么问题
- 登录态、Cookie、Token 为什么不对
- Local Storage / Session Storage / IndexedDB 里到底存了什么
- Cache Storage 是否缓存了旧资源
- Service Worker 是否接管请求
- Manifest、离线能力、PWA 状态是否正确
常见查看区域
- Cookies
- Local Storage / Session Storage
- IndexedDB
- Cache Storage
- Service Workers
- Manifest
常见使用场景
- 登录态明明写入了，为什么请求没带
- 切环境后页面仍读到旧缓存
- 离线资源、PWA 安装、更新流程异常
- Service Worker 导致的“代码改了但页面没变”
实用排障习惯
- Network 和 Application 一起看
- 确认是“服务端没发”还是“浏览器没存”还是“请求没带上”
- 遇到缓存疑难问题时，先看 Cache Storage 和 Service Worker，再决定是否清站点数据
继续往下拆
边界与易混淆点
- Application 面板显示的是浏览器本地状态，不直接证明服务端状态
- Cookie 是否带上请求，还要回到 Network 面板 看真实请求
- “页面没更新”不一定是打包问题，也可能是 Service Worker 或 Cache Storage
学习检查
- Application 面板与 Network 面板分别能直接证明什么？
- Cookie、localStorage、IndexedDB、Cache Storage、Service Worker 五类状态为什么不能混成一个“浏览器缓存”概念？
- Application 里看得到 Cookie，为什么还不能证明下一次请求一定会带上？
- 页面显示旧数据时，怎样区分 HTTP cache、Cache Storage、IndexedDB 和应用内 state？
- Service Worker 已激活为什么仍不能推出当前请求一定由它处理？
- 给一个“登录后刷新又退出”的案例，说明需要联动哪些 Application/Network 证据。
Digital Biome