需借助工具链模拟渲染路径识别未用css，静态分析易误删动态类，推荐purgecss-webpack-plugin处理自定义全局样式并配置白名单，coverage仅作线索不可直接删。
怎么判断CSS文件里哪些样式真的没被用到
浏览器本身不主动报告“某条CSS规则从未匹配过元素”，所以得靠工具链辅助。核心思路是：让工具模拟真实页面渲染路径，记录所有实际生效的CSS选择器，再和源文件比对。
常见错误现象：purgecss 扫描后删掉关键样式，页面错乱；unused-css 报告大量“未使用”，但其实是 JS 动态插入 class 导致的误判。
- 必须覆盖所有路由和交互状态（比如 hover、.is-open、[data-loading]），否则工具会把它们当无用
- 如果项目用
React或Vue，组件级 scoped CSS 或动态 class 名（如className={styles[status]}）需要额外配置白名单 -
playwright或puppeteer驱动的检测比静态分析准，但构建耗时明显增加
Webpack 项目里怎么安全地删除未使用 CSS
直接删 node_modules 里的第三方 CSS 很危险——很多库的样式依赖运行时条件（比如 ant-design 的暗色主题类在 JS 加载后才加到 ）。重点该清理的是自己写的、全局引入的 CSS 文件。
推荐用 purgecss-webpack-plugin + glob-all，它能读取 HTML 模板和 JS 中的字符串字面量，识别出可能用到的 class 名。
立即学习“前端免费学习笔记（深入）”；
- 别把
tailwind.css或bootstrap.min.css直接丢给 PurgeCSS，它们本身已是精简版；重点盯src/styles/global.css这类自定义文件 - 配置
whitelistPatterns必须包含正则，比如/^ant-/或/^js-/，否则ant-collapse-item这种动态生成的 class 会被误删 - 开启
rejected: true选项，它会在构建日志里输出被删掉的选择器，方便人工核对
为什么 Chrome DevTools 的 Coverage 工具不能直接删 CSS
Coverage 面板显示的是“当前页面加载过程中，CSS 字节有多少被解析并尝试匹配”，不是“是否最终影响了渲染”。它会把媒体查询未命中、@supports 不通过、甚至注释里的选择器都算作“未使用”。
典型误操作：看到 global.css 显示 78% 未覆盖，就手动删掉里面所有标灰的规则——结果下次用户切到 iPad 就发现布局崩了。
-
Coverage只反映单次加载快照，无法覆盖响应式断点切换、用户偏好（如 prefers-reduced-motion）、JS 后续添加的 class - 它对
@import和@layer的处理不稳定，嵌套导入的文件可能完全不计入统计 - 真正该做的是把它当线索：标灰区域对应哪些组件？再去查那些组件的模板和 JS，确认 class 是否真没被引用
内存溢出其实很少是纯 CSS 引起的，但 CSS 会放大问题
单个 CSS 文件再大，解析后占用的内存也远小于 JS bundle。真正触发内存溢出的，往往是 CSS + 大量 Web Components + 频繁重绘的组合——比如用 lit 渲染几百个带阴影/渐变/滤镜的卡片，每个卡片还带独立 scoped style 标签。
这时候删 CSS 不解决问题，得改架构：
- 把重复的视觉效果抽成 CSS 自定义属性，而不是为每个组件写一套
box-shadow值 - 避免在
:hover或@keyframes里用transform: scale(1.001)这类触发 layout 的写法 - 检查是否有插件在 runtime 动态注入 style 标签（比如某些图表库），这类注入不走构建流程，PurgeCSS 完全看不见
最常被忽略的一点：CSS @import 嵌套层级超过 4 层时，V8 的 CSS 解析器会显著增加内存驻留时间，尤其在低端 Android 设备上——这不是代码逻辑问题，是引擎限制。
