应采用「运行时检测 + 静态分析」双路验证：先用 DevTools Coverage 面板识别未使用规则，再用 Puppeteer 模拟 SPA 路由补全动态样式；uncss 仅作初筛，需人工核验 JS 动态类、伪类及媒体查询；批量清理须经灰度前缀标记、7 天零调用监控、Git tag 回滚保障。
怎么快速定位长期没动过的 CSS 文件里哪些规则已失效
靠人眼扫几百个 .css 文件不现实，真正有效的是「运行时检测 + 静态分析」双路验证。先用浏览器 DevTools 的 Coverage 面板（Ctrl+Shift+P → 输入 Coverage）跑一遍真实访问路径，它会标出每行 CSS 的使用率；再配合 puppeteer 自动化访问关键页面，导出未命中样式列表。注意：Coverage 只反映当前页面加载的 CSS，SPA 路由切换后动态插入的样式可能被漏掉，得补上模拟跳转逻辑。
为什么 uncss 对老项目经常误删、不敢直接上线
uncss 默认只分析 HTML 中静态存在的 class 名，对 JS 动态拼接的类名（比如 el.classList.add('is-' + status)）、CSS-in-JS 注入、或通过 [class*="icon-"] 这类属性选择器匹配的规则，统统识别不了。常见误删现象包括：图标类消失、状态切换动画失效、响应式断点类被清空。建议把它当「初筛工具」，输出结果必须人工对照 DOM 快照和 JS 逻辑交叉验证，尤其检查 data- 属性驱动的样式、伪类（:hover, :focus-within）和媒体查询。
如何安全地批量删除无用 CSS 类而不崩掉历史页面
不能直接删源码，得走「灰度剔除」流程：
- 把待清理的类名统一加前缀（如
old-xxx），用postcss插件自动重写，并在生产环境开启 CSS 模块化隔离 - 在 Nginx 或 CDN 层配置日志记录，监控含
old-前缀类名的页面 PV 和报错（如ReferenceError: old-button is not defined—— 实际是 JS 里还引用着旧类） - 确认连续 7 天零调用后，再执行真实删除；同时保留 Git tag 标记清理批次，方便回滚
老项目常有隐藏依赖：某个被遗忘的 iframe 页面、后台管理页的弹窗组件、甚至打印样式表（@media print）里的规则，都可能只在特定条件下触发。
立即学习 “ 前端免费学习笔记（深入）”；
PostCSS 插件链里哪些步骤会放大清理风险
postcss-preset-env 和 cssnano 在压缩阶段可能合并、重命名类名，导致 uncss 或覆盖率工具看到的类名跟源码对不上。更危险的是 postcss-discard-comments 删除了带标记的注释（比如 /* keep: legacy-grid */），让后续维护者失去人工标注线索。建议清理前固定构建版本，禁用所有类名混淆插件，并在 postcss.config.js 里显式关闭 cssnano 的 reduceIdents 和 zindex 优化。
真正麻烦的从来不是“哪些能删”，而是“删完谁来担责”。老系统里一个 .hidden 类可能同时被三套 JS 框架、两个 CMS 插件和一份 PDF 导出逻辑共用，连注释都没写清楚。动手前，先 grep 全局调用，再看 Git blame 最后一次修改时间——三年没人碰的 CSS，往往藏着最要命的兼容性补丁。
