Chrome DevTools Coverage面板显示未执行的CSS字节，但不等于可安全删除——需结合交互覆盖、动态样式验证及构建产物结构综合判断。
Chrome DevTools 的 Coverage 面板能直接告诉你哪些 CSS 字节压根没执行过，但**它不等于“可安全删除”的清单**——漏交互、错路径、动态类名都会让它误报或漏报。
Coverage 面板怎么开、怎么录才有效
别只点一次刷新就收工。Coverage 统计的是「当前页面加载 + 当前视口 + 当前交互状态」下的字节执行情况，不是全量快照。
- 打开方式：
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（Mac），输入Coverage→ 选Show Coverage - 必须点
Reload按钮（带循环箭头的那个），不是手动按 F5 —— 否则不触发录制 - 单页应用（SPA）要先跳转到各路由（比如 /dashboard、/profile），每换一个路由都点一次
Reload coverage - 所有可交互态都要覆盖：展开折叠菜单、触发表单校验、模拟网络错误、点 loading 按钮、拖动滚动条到底部……否则红色部分可能只是“还没轮到它用”
为什么 Coverage 显示某条 CSS 是红色，删了却出问题
红色只代表「这次录制中没执行」，不代表逻辑上无用。常见假阳性场景：
-
@media查询在当前视口宽度下未命中（比如只在min-width: 1200px下生效，但你用的是 900px 宽浏览器窗口） - JS 动态插入的样式：
document.styleSheets[0].insertRule('.foo{color:red}', 0)—— Coverage 根本看不到这条规则从哪来 - 通过
MutationObserver监听 DOM 变化后追加的 class，比如el.classList.add('is-open')，但录制时没触发该 observer - CSS-in-JS 库（如 Emotion、Styled Components）生成的运行时样式，不会出现在原始 .css 文件里，Coverage 对它完全不可见
如何交叉验证 Coverage 结果是否真能删
单靠 Coverage 下结论太危险。得用至少一种辅助手段反向确认：
立即学习“前端免费学习笔记（深入）”；
- 在
Elements面板里右键某个元素 →Break on > attribute modifications，然后手动触发疑似被删功能（如点击按钮），看是否动态加了 class 或 style —— 如果加了，对应类名就得进safelist - 搜索项目代码里所有
classList.add、className +=、setAttribute('class',等调用，把拼接出的类名正则写进 purgecss 的safelist（例如/^is-.+$/、/^text-[a-z]+$/） - 用
chrome-devtools-protocol抓真实渲染时的 computed styles：启动 Puppeteer，遍历所有页面状态，调用DOM.getComputedStyleForNode，比对哪些 computed 属性实际来自哪些 CSS 规则 - 对 Tailwind 项目，别用独立的
purgecss，改用tailwind.config.js的content字段——它基于 AST 解析，能识别class={\`btn \${loading ? 'loading' : ''}\`}这类模板字符串
删完之后必须做的三件事
Coverage 是起点，不是终点。删 CSS 后不验证，等于埋雷：
- 在移动设备模拟器里重跑 Coverage，检查响应式断点是否意外崩坏（比如
@media (prefers-reduced-motion)被删，但用户开了系统精简动画） - 用 Lighthouse 的
Unused CSS审计项再扫一遍，它用不同策略采样，有时能补 Coverage 漏掉的分支 - 重点看 JS 错误日志：有些组件依赖 CSS 类名做存在性判断（如
if (el.classList.contains('has-error'))），删了类但没删 JS 逻辑，会引发静默失败
最常被忽略的一点：Coverage 统计的是字节级使用率，不是选择器级。一条 .header nav ul li a:hover::before 规则哪怕只用了其中 1 字节，整行都会标绿；而一个 2KB 的 utility class 块如果只用了一个 mt-2，其余 1999 字节都是红的——但你不能只删那 1999 字节，因为构建工具根本不会拆开打包。所以覆盖率数据得结合构建产物结构一起读。
