purgecss

项目背景与痛点

前端工程化走到今天，"CSS 体积失控"几乎成了一个公开的秘密。我们习惯用 Tailwind、Bootstrap、Ant Design 这类工具库快速搭界面，结果产物里往往躺着一大半永远不会被 HTML 引用的样式规则——整份组件库的样式被全量打包，实际用到的可能不到三成。手写 CSS 也好不到哪去：迭代几轮之后，谁也不敢确定某个类名是不是死代码，删掉怕线上崩，留着又占用首屏带宽。

这正是 purgecss 切入的缝隙。它不做 CSS-in-JS，不干预构建流程的写法，只干一件事：扫描源码里实际出现的选择器，把样式表中未被引用的规则安全地剔除。听起来像暴力字符串匹配，但真正做到"安全"却极难——动态拼接的类名、伪类状态、正则生成的选择器，都会让简单的匹配器误杀线上样式。purgecss 的价值，就在于它把这件事工程化、可配置化，并沉淀为一套"保守剥离"的策略。

核心技术揭秘

purgecss 的定位是"选择器级别的静态分析器"，而非 CSS 解析器的简单封装。它内部大致分为三段流水线：内容提取 → 选择器匹配 → 输出裁剪。

首先，它用 postcss 把目标 CSS 解析成 AST，同时遍历 HTML/JS/模板文件，把源码中的文本片段整理成"候选字符串集合"。但这里并非纯文本比对——它会用一组可配置的提取器（extractor），从源码里识别出类名、id、标签名等可能的引用标记，并允许通过自定义正则处理动态模板（如 className={btn-${size}}）。这一层是整个工具误判率的分水岭。

接着是核心匹配逻辑：对 AST 中的每条规则，提取其选择器，拆解为简单选择器集合，在候选集合中寻找引用。这里有个关键设计——它默认保留"被认为可能被动态使用"的选择器，并允许通过 safelist、blocklist 精确介入。匹配策略上遵循"宁可多留，不可误删"的保守原则。

最后一步把命中结果写回 AST，交给 postcss 重新序列化，输出裁剪后的 CSS。整个过程是无状态的、可并行的，也因此易于嵌入 webpack、Vite、Gulp 等各类构建链路。

功能亮点与差异

和同类工具（如 UnCSS、PurifyCSS）相比，purgecss 的差异化不在"删得多"，而在"删得准、删得可控"。

其一是提取器可插拔。UnCSS 依赖真实渲染 DOM，重且慢；purgecss 走纯静态分析，速度快一个量级，并允许你针对 Vue、React、Svelte 各自的模板语法写专用 extractor，把动态类名纳入白名单。

其二是safelist 的精细度。它区分了普通白名单、正则白名单、以及"基于深层选择器"的保留，能覆盖 hover:、md: 这类变体前缀与状态组合。这种颗粒度正是大型项目敢用的底气。

其三是与生态的贴合。官方提供 PostCSS 插件、webpack 插件、CLI 三套形态，几乎覆盖了所有主流构建方式，你不需要为了用它重构整条流水线。

应用场景与落地建议

最适合的落点是样式体量明显大于实际使用量的项目：引入重型 UI 组件库、或用原子化 CSS 框架的团队。典型收益是产物 CSS 缩小 50%~80%。

落地时有几个必须踩过的坑：第一，动态类名务必写 safelist 或定制 extractor，别指望它猜出 \text-${color}-500``；第二，保留伪类与变体，Tailwind 的状态类最容易在首次接入时被误删；第三，先跑一遍 diff 再上线，purgecss 支持保留被删规则的报告，务必审查一遍再全量启用；第四，与 SSR、按需加载协同，别让裁剪发生在服务端已缓存 CSS 之后。生产环境建议把它当作 CI 环节的一个"减法检查"，而非一次性脚本。

综合评价

优点很清晰：轻量、快速、配置灵活，静态分析路径让它几乎不增加构建负担；safelist 机制给了工程团队足够的安全垫；生态集成成熟，落地成本低。

缺点同样真实：静态分析的先天局限——任何完全动态生成、又没进白名单的类名都是潜在的线上事故点，它对"代码可分析性"有前置要求；配置文件与 extractor 的学习曲线对新手不算友好；面对 CSS-in-JS 全动态场景基本无力。另外，它不负责压缩、去重、合并等价规则——这些是 cssnano 的活，别指望它一把梭。

一句话总结：purgecss 不是"一键瘦身"的魔法棒，而是一把需要你亲自磨刀、认准边界的精准手术刀。 用得好，它是首屏优化的利器；用不好，它就是线上样式的定时炸弹。