Chrome DevTools Coverage定位未使用CSS并验证删除风险

删除一段“看起来没用”的 CSS，真正危险的地方不在 Coverage 面板本身，而在于你只录了一页、只看了首屏，或者没有触发展开菜单和弹窗。更稳妥的做法是：先用 Chrome DevTools Coverage 找到候选资源，再按页面路径和动态状态复测，最后回到源码确认归属，改完后重新走一遍关键路径。

官方地址：https://developer.chrome.com/docs/devtools/coverage

从 Command Menu 打开 Coverage 并开始采集

先在开发环境打开要分析的页面，按 Ctrl+Shift+P（macOS 使用 Command+Shift+P）打开 DevTools 的 Command Menu。输入 coverage，点击 Show Coverage。进入 Coverage 面板后，把类型筛选切到 CSS，再点击 Start instrumenting coverage and reload page。

重新加载完成后，面板会列出当前加载的 CSS 资源，并显示 Total Bytes、Unused Bytes 和使用可视化条。先记录资源名称和比例，不要立刻改文件。一次采集只代表本次加载场景，不能代表整个站点。

按页面路径触发动态状态，避免只看首屏

把要保护的路径列成小矩阵，再逐个打开页面并触发真实交互。重点不是把页面数量堆得很大，而是覆盖会改变 class、插入节点或切换媒体查询的状态。

如果同一 CSS 文件在不同路径上的使用比例明显变化，先把它标为“场景相关”，不要按最低比例计算可删除量。组件库、主题变量和按需加载样式尤其容易在首屏没有命中、交互后才出现。

打开逐行视图并验证 CSS 删除风险

在 Coverage 资源列表中点击目标 CSS 文件，DevTools 会把它带到 Sources 的逐行视图。沿着未使用标记找到候选片段后，回到项目源码搜索选择器、媒体查询或构建入口，确认它不是压缩合并后的第三方文件，也不是由运行时拼接出来的规则。

候选规则至少要回答三件事：它属于哪个组件；哪些页面和状态已经覆盖；删除后是否会影响主题、响应式布局或异步模块。对于只出现一半使用标记的行，也不要整行删除，先拆分声明或定位同一行中的不同规则。

修改后用同一矩阵做回归

确认候选后再做最小修改，并保留一次可回滚的提交。删除后重新启动 Coverage 采集，依次检查首页、搜索结果、弹窗和移动布局。验收不只看 CSS 字节是否下降，还要看关键元素是否仍有正确的布局、可见性和交互反馈。

一个实用的收尾清单是：资源仍能加载；关键路径没有新增控制台错误；菜单和弹窗可以打开关闭；窄视口没有横向溢出；主题色、焦点态和禁用态仍然存在。若某个规则只在低频路径命中，就把它交给路径负责人确认，而不是因为 Coverage 里暂时偏红就删除。

相关问题

Coverage 显示未使用 CSS，是否可以直接删除？

不可以。它表示当前录制场景没有命中，至少还要覆盖主要页面、动态状态和响应式布局，并回到源码确认规则归属。

为什么重新加载后使用比例还会变化？

异步组件、用户交互、路由切换和媒体查询都会改变实际命中的规则，重新加载只是重置并重新记录当前场景。

压缩后的 CSS 怎么定位到源码？

优先利用 Sources 的资源行、构建映射和选择器搜索；如果没有可靠的映射，就先在构建配置中确认产物来源，避免直接编辑压缩文件。