Chrome DevTools Coverage在localhost IIS下显示app.css100%未用但实际生效

Chrome DevTools的Coverage工具不存在对localhost本地环境的适配限制，你遇到的「app.css被标记为100%未使用但样式实际生效」的异常，是工具采样逻辑与本地调试场景不匹配导致的常见误报，和是否使用IIS搭建localhost环境没有直接关联。

误报的核心触发原因 #

Coverage工具对CSS使用率的统计逻辑，是在指定采样周期内，捕获浏览器真实完成样式计算、匹配DOM节点的规则条目，出现统计结果和实际生效情况脱节的场景，通常由三类原因触发：

• 采样启动时机早于CSS解析完成
  如果你习惯先打开Coverage录制状态，再刷新页面开始统计，IIS本地调试环境通常会为静态资源配置无缓存规则，会导致Coverage采样器启动时，app.css的内容还未被浏览器解析注入到内置样式表中，采样器无法统计到任何已使用的规则。哪怕后续CSS正常加载、样式完整生效，已经生成的覆盖率标记也不会自动同步更新，最终就会出现整份文件100%未使用的标记。
• 静态资源响应配置异常
  IIS默认的静态资源MIME类型配置如果出现偏差，app.css的响应头Content-Type不是标准的text/css，浏览器会基于文件后缀名的兼容逻辑正常解析应用样式，但Coverage工具无法将返回内容关联到可统计的样式表资源，就会将整份文件判定为未使用。
• 动态触发的样式未被采样覆盖
  如果app.css内的规则需要通过用户交互（点击、切换、滚动）才会匹配DOM，而你在停止Coverage录制前没有触发对应的交互动作，已经被应用但未在采样周期内完成计算的规则，就不会被计入已使用的统计值，极端场景下会出现整份文件使用率为0的误判。

可落地的解决步骤 #

按以下优先级操作即可得到准确的覆盖率统计结果：

1. 调整Coverage的录制启动顺序
   先完成页面首次加载，确认所有样式正常渲染后，再打开DevTools的Coverage面板，选择「重新加载页面并开始录制」，等待页面完全加载、静态资源全部传输完成后，手动停留3秒再停止录制，查看统计结果。
2. 检查app.css的响应头配置
   在Network面板找到app.css的请求记录，确认两个核心配置项：

• 响应头的Content-Type值为text/css; charset=utf-8
• 响应头没有设置过长的强缓存规则，避免Coverage采样时读取到历史版本的资源内容

3. 补全交互触发的样式采样
   停止Coverage录制前，手动操作页面上所有可交互的元素（点击按钮、展开折叠面板、切换标签页、滚动页面到不同区块），让所有依赖交互才会匹配的CSS规则完成真实的样式计算，再查看最终的覆盖率统计值。

内容的提问来源于stack exchange，提问作者Samuel