不能，Coverage面板不测响应式CSS性能，只标识未参与样式计算的规则；需多视口录制、交互触发及交叉验证，避免误删实际生效的@media等规则。
Coverage 面板能测响应式 CSS 的性能吗？不能，但它能暴露关键问题
Coverage 不是性能分析工具，它不测渲染耗时、重排重绘或布局抖动。它只回答一个朴素问题：「这条 CSS 规则在当前录制过程中，有没有参与过任何元素的样式计算？」——所以它对响应式 CSS 的价值，在于快速揪出「被加载却从未触发」的规则，比如 @media (max-width: 480px) 在桌面视口下标红，就是正常现象；但如果在手机视口下它依然标红，才说明断点失效、选择器写错，或媒体查询条件根本没命中。
怎么让 Coverage 真实反映响应式行为？必须覆盖多视口 + 多交互
默认只刷新一次页面，Coverage 只捕获首屏初始状态。响应式逻辑往往藏在视口变化、悬停、展开等动作里，漏掉就全是假阳性。
- 先用设备模拟器切到目标尺寸（如
iPhone SE），再点 Coverage 的↻ Reload and start recording按钮重载录制 - 手动拖动窗口宽度跨越关键断点（如从 769px 拖到 767px），观察
@media内部规则是否由红变绿 - 对
:hover、:focus类规则，得真去悬停按钮、点击输入框，Coverage 才会标记为已使用 - 单页应用（SPA）要逐个访问路由，每个页面单独点一次
↻，切换路由不会自动重置统计
为什么 @media 规则总被标红？先分清“未触发”和“写错了”
红色本身不危险，危险的是误删本该生效的规则。常见混淆点：
-
@media (prefers-color-scheme: dark)在亮色系统下标红，是预期行为；但若你在深色模式下仍标红，检查是否漏写了meta或系统设置未生效 -
@media screen and (min-width: 1200px)在 1280px 宽度下还是红的？可能选择器没匹配上：比如写了.header--large，但 HTML 里是class="header-large"（少了个连字符） -
@supports (display: grid)内部规则标红，不代表 Grid 不支持——Coverage 不执行特性检测逻辑，它只看浏览器是否真的把这条规则应用到了某个元素上 - 用
rem或em做断点（如@media (min-width: 40rem)）时，根字体大小被 JS 动态改过？Coverage 录制期间的计算值可能和运行时不一致
删掉 Coverage 标红的响应式 CSS 前，必须交叉验证这三件事
直接删 @media 块风险极高。Coverage 只告诉你“这次没用”，没告诉你“永远不用”。
立即学习“前端免费学习笔记（深入）”；
- 在
Sources面板里点开标红的 CSS 文件，把鼠标悬停在红色行上，看提示是不是This rule is not used；如果是This rule is overridden，说明它被用了，只是被更高优先级样式盖掉了 - 用
Console执行matchMedia('(max-width: 768px)').matches，确认媒体查询当前是否为true；再查document.querySelectorAll('.your-class')，确认目标元素确实存在且可见 - 右键目标元素 →
Break on > attribute modifications，刷新后看 JS 是否动态移除了 class 或插入了新 DOM，导致 Coverage 漏判
真正难处理的，是那些依赖用户滚动、懒加载、权限状态才生效的响应式逻辑——Coverage 捕不到，也不能靠它做决策。这类规则得结合 Lighthouse 的 Unused CSS 审计、PurgeCSS 的静态扫描，再加人工走查。
