Coverage面板的“未使用代码”不等于首屏冗余代码，因其仅按运行时执行标记而无视时机；需结合Performance面板锁定FP至LCP间首屏执行区间，再重载录制文件分析，并过滤聚焦业务bundle中大块未使用、具业务语义的模块。
Coverage 面板显示的“未使用代码”不等于首屏冗余代码
Coverage 面板（Ctrl+Shift+P → Toggle Coverage）只按「运行时是否执行过」标记 JS/CSS 行，但它完全不区分执行时机。哪怕某段代码在 DOMContentLoaded 后 3 秒才被调用（比如懒加载模块、折叠面板逻辑），也会被标为“已使用”，从而漏掉大量首屏无关代码。反过来，有些首屏必需的代码（如 polyfill、CSS-in-JS 初始化）若因条件分支未进入，又会被误标为“未使用”。关键不是看红/绿比例，而是看“谁在首屏关键路径上执行了、谁没执行但本不该存在”。
必须配合 Performance 面板录制首屏关键帧
打开 Performance 面板 → 勾选 Enable advanced paint instrumentation（确保能识别首屏渲染完成点）→ 点击录制 → 刷新页面 → 等首屏内容稳定（文字可读、主图可见、交互可用）后停止。在火焰图中定位 FP（First Paint）和 FCP（First Contentful Paint）之后、LCP（Largest Contentful Paint）完成前的时间窗口——这就是你要分析的“首屏执行区间”。右键该时间范围 → Save profile，再打开 Coverage 面板重新加载该录制文件，它才会把“此时间段内未执行的代码”作为首屏冗余候选。
过滤 Coverage 结果：只关注首屏 JS bundle 中的未使用部分
Coverage 面板默认列出所有资源，包括 node_modules、polyfills、webpack runtime，这些干扰项必须手动排除：
- 在 Coverage 表格顶部搜索框输入
.js，再逐个点击文件名左侧的折叠箭头，只展开你项目自己的 bundle（如main.xxx.js、app.xxx.js，避免点开vendor或chunk） - 忽略覆盖率 >90% 的小工具函数（如
debounce、throttle），它们大概率被框架或组件间接调用，Coverage 捕捉不到调用链 - 重点关注：大块未使用区域（连续 50+ 行灰色）、带明显业务语义的模块（如
ProductDetailModal、CheckoutFlow），尤其是它们被 import 但从未触发 render 或事件监听器 - 验证方式：临时注释掉疑似冗余模块的
import语句，重跑首屏录制，确认 FCP/LCP 时间无变化且 UI 无报错
警惕 CSS 覆盖率的假阳性：class 名动态拼接会让 Coverage 失效
Coverage 对 CSS 的判定基于「浏览器是否解析并应用了某条规则」，但如果你用 classNames、styled-components 或 emotion 动态生成 class 名，实际生效的样式规则可能根本不在原始 CSS 文件里。此时 Coverage 显示某个 .button--primary 未使用，不代表它冗余——它可能被运行时字符串拼接成 button--primary__hash123 后才生效。更可靠的做法是：Ctrl+F 在 Sources 面板搜索该 class 名是否出现在 JS 字符串中；或者用 Elements 面板选中首屏元素，看 Computed 样式里是否真有对应声明。
真正决定首屏冗余度的，从来不是 Coverage 数字本身，而是你能否把“未执行”和“首屏不需要”严格对齐。很多团队卡在第一步：没锁定首屏时间窗口就看 Coverage，结果优化了半天，LCP 毫无改善。
