CSS 无用代码清理工具深度对比：PurgeCSS vs Purify-css vs UnCSS

在前端工程化体系中，移除未使用的 CSS 是优化加载性能的关键步骤。purgecss、purify-css 和 uncss 都致力于解决同一问题，但它们的实现原理、维护状态和适用场景截然不同。本文将从架构师视角深入分析这三者的技术细节，帮助你在构建流程中做出正确选择。

🚦 维护状态与生命周期

选择工具的首要标准是项目的活跃度。依赖已停止维护的库会给项目带来安全隐患和构建失败风险。

purgecss 是目前唯一活跃维护的项目。

• 定期发布更新，修复 Bug 并适配新 CSS 语法。
• 拥有完善的插件生态（Webpack, PostCSS, CLI）。

# 安装最新稳定版
npm install -D purgecss

purify-css 已处于事实上的废弃状态。

• 最后一次主要更新已是多年前。
• 无法处理现代框架（如 Vue 3, React 18）生成的动态类名。

# 不推荐安装，仅用于理解旧代码
npm install purify-css

uncss 依赖已死亡的技术栈。

• 核心依赖 PhantomJS，该项目已于 2018 年停止维护。
• 在现代 Node.js 版本中安装极易失败。

# 强烈避免使用
npm install uncss

⚙️ 工作原理：静态分析 vs 运行时 DOM

理解工具如何判断 CSS 是否被使用，有助于配置正确的策略。

purgecss 基于静态文件分析。

• 扫描 HTML、JS、模板文件中的类名字符串。
• 速度快，不依赖浏览器环境。
• 缺点：无法检测动态拼接的类名（除非配置安全名单）。

// purgecss: 静态分析配置
const PurgeCSS = require('purgecss').PurgeCSS;
const purgeCSSResults = await new PurgeCSS().purge({
  content: ['./src/**/*.html', './src/**/*.js'],
  css: ['./src/**/*.css']
});

purify-css 同样基于静态分析。

• 原理与 PurgeCSS 类似，但算法较旧。
• 对复杂选择器的识别率较低。

// purify-css: 静态分析配置
const purify = require('purify-css');
purify(['src/**/*.js'], ['src/**/*.css'], {
  minify: true
}, function(result) {
  console.log(result); 
});

uncss 基于运行时 DOM 分析。

• 启动 headless 浏览器加载页面，检查实际渲染的节点。
• 能准确识别动态生成的类名。
• 缺点：极慢，配置复杂，依赖重。

// uncss: 运行时分析配置
const uncss = require('uncss');
uncss(['http://localhost:3000'], {
  css: ['src/**/*.css']
}, function(error, output) {
  console.log(output);
});

🛡️ 安全性与白名单机制

误删 CSS 是此类工具最大的风险。完善的白名单（Safelist）机制至关重要。

purgecss 提供灵活的白名单配置。

• 支持正则表达式匹配动态类名。
• 支持在 CSS 注释中直接标记保留。

/* purgecss start ignore */
.no-remove {
  color: red;
}
/* purgecss end ignore */

// purgecss: 配置白名单
await new PurgeCSS().purge({
  content: ['./src/**/*.html'],
  css: ['./src/**/*.css'],
  safelist: [/^btn-/, 'active'] // 保留 btn- 开头和 active 类
});

purify-css 白名单功能有限。

• 仅支持简单的字符串匹配。
• 对复杂动态类名支持不足。

// purify-css: 简单白名单
purify(files, css, {
  whitelist: ['active', 'modal']
}, callback);

uncss 依赖页面覆盖度。

• 理论上不需要白名单，因为它看的是实际渲染。
• 但如果构建时无法访问所有路由状态，仍会漏删或误删。

// uncss: 依赖 URL 覆盖
uncss(['http://localhost/home', 'http://localhost/about'], options, callback);
// 如果没访问 /contact 路由，该页面样式可能被误删

🧩 构建工具集成体验

现代开发离不开构建工具集成。集成难度直接影响开发效率。

purgecss 拥有官方维护的插件。

• 支持 Webpack, PostCSS, Gulp, CLI。
• 配置简单，文档清晰。

// webpack.config.js (PurgeCSS)
const { PurgecssPlugin } = require('purgecss-webpack-plugin');
module.exports = {
  plugins: [
    new PurgecssPlugin({
      paths: glob.sync(`${PATHS.src}/**/*`,  { nodir: true })
    })
  ]
};

purify-css 集成较为陈旧。

• 缺乏对新版 Webpack 的官方支持。
• 通常需要自定义 loader 或脚本。

// 旧式集成示例
const PurifyCSSPlugin = require('purifycss-webpack');
// 注意：此插件可能不兼容 webpack 5+

uncss 集成成本最高。

• 需要启动本地服务器供其抓取。
• 在 CI/CD 流水线中配置繁琐。

// uncss-webpack-plugin 示例
const UnCssPlugin = require('uncss-webpack-plugin');
// 需要配置 server 选项，增加了构建复杂度

📊 核心特性对比总结

💡 架构师建议

purgecss 是现代前端工程的唯一理性选择。它平衡了性能、安全性和易用性。对于动态类名问题，应通过规范代码风格（避免过度动态拼接类名）配合白名单解决，而不是退回到使用过时的运行时分析工具。

purify-css 和 uncss 应被视为技术债务。如果你的项目正在使用它们，建议制定迁移计划，逐步替换为 purgecss。特别是 uncss，其依赖的 PhantomJS 存在已知安全漏洞，不应出现在任何生产环境中。

最终结论：在新项目中，请直接锁定 purgecss。它不仅是工具，更是社区公认的标准实践。