Lightning CSS：Rust 写的极速 CSS 解析、转换与压缩引擎

在前端构建工具链里，CSS 处理长期是个”老大难”：PostCSS 生态强大但慢，CSSNano 压缩质量高但要走多趟 JS AST，esbuild 快但 CSS 能力偏薄。由 Parcel 团队用 Rust 编写的 Lightning CSS 试图一次解决”解析（parser）→ 转换（transformer）→ 打包（bundler）→ 压缩（minifier）“全链路。官方宣称它”比同类 JavaScript 工具快 100 倍以上”，单线程每秒能压缩超过 270 万行 CSS。

本文基于 lightningcss.dev 官网与官方仓库，拆解它到底快在哪、产物小在哪，以及那些 benchmark 背后的口径。

一、背景：CSS 处理为什么慢

传统 JS 工具链处理 CSS 的慢，根因有三：

1. 每趟工具都要重新解析一遍 CSS——PostCSS、autoprefixer、cssnano 各自把 CSS 字符串解析成 AST，跑一遍再序列化，多趟叠加；
2. JS 本身的动态对象表示内存开销大，AST 节点是带隐藏类的 JS 对象；
3. 压缩优化需要跨规则全局信息，而 JS 实现要为此反复遍历。

Lightning CSS 的对策是：用 Rust 写一个原生编译器，把解析、转换、压缩合并到尽量少的 AST 遍历里，并在内存里用紧凑的数据结构表示样式规则。

二、它是什么

Lightning CSS 自称是”an extremely fast CSS parser, transformer, bundler, and minifier”。它的几个关键身份：

• 底层站在 Mozilla 肩膀上：直接使用 Firefox 浏览器引擎同款的 cssparser 和 selectors 两个 Rust crate 做词法/选择器解析，因此”像浏览器一样完整解析每一条 CSS 规则、属性和值”，而不是用正则猜。
• 现代 CSS 降级器：让你今天就写 CSS nesting、oklab()、custom media query、逻辑属性、高色域颜色，再根据你指定的 targets（如 last 2 versions）自动转译成兼容语法，并自动补厂商前缀。
• 压缩器：合并长写属性为简写、移除多余前缀、合并兼容的相邻规则、删默认值、化简 calc()、缩短颜色、压缩渐变。
• CSS Modules 实现：对 class、id、@keyframes、CSS 变量做局部作用域，生成原名→作用域名的映射，并支持把未使用的 class/变量 tree-shake 掉。

三、技术机制

Lightning CSS 把一条 CSS 规则解析成一个强类型的 Rust 枚举结构。官网给了一个 background 属性的解析结果示例——每一个子属性（颜色、位置、repeat、size、attachment、origin、clip）都是明确的类型，而不是字符串。这种”一次性解析成结构化 AST”的好处是：

• 后续的前缀补全、降级、压缩都在同一份 AST上做，不用反复解析；
• 因为知道每个值的确切类型，压缩器可以安全地做长写转简写、颜色缩短等优化，而不靠字符串替换猜。

降级的例子很能说明问题。输入：

.foo { color: oklab(59.686% 0.1009 0.1192); }

针对 last 2 versions 的输出会自动生成多档回退：

.foo {
  color: #c65d07;
  color: color(display-p3 .724144 .386777 .148795);
  color: lab(52.2319% 40.1449 59.9171);
}

即从最兼容的 hex，到 display-p3，再到 lab，按浏览器支持度逐层递进。

四、关键数据：速度与产物体积

官网用同一份 **Bootstrap 4（约 1 万行 CSS）**做了两组对比，我们把数字完整列出：

换算一下：相对 CSSNano，Lightning CSS 快了约 131 倍（544.81 / 4.16），这就是”100ד说法的来源；相对同样极快的 ESBuild，则快约 4 倍（17.2 / 4.16）。体积上，Lightning CSS 比另外两者小约 10%–11%（139.74 KB vs ~156 KB）。

五、评测方法与口径批判

这组数字看着漂亮，但有几个口径需要读者自己权衡：

1. “快 100 倍”是相对 JS 工具（CSSNano），不是相对所有快工具。和 ESBuild 比只有约 4 倍差距；如果读者已经在用 esbuild/Rspack，增量收益没有 100× 那么夸张。
2. 基准只有一个固定文件 Bootstrap 4（约 1 万行）。真实项目往往是几百个小文件、带 source map、带 CSS Modules 作用域哈希、还要做打包（bundle），单次压缩大文件的优势在多文件开销下会被摊薄。
3. “每秒 270 万行”是单线程吞吐宣传值。用 Bootstrap 反推：1 万行 / 4.16ms ≈ 每秒 240 万行，与宣传值同量级，但这是最优热路径下的数字，不含解析出错、source map、降级计算等开销。
4. 体积优势（约 10%）才是它相对 esbuild 的真正差异点——但这个差距对首屏性能的实际影响，往往小于 gzip/brotli 本身带来的压缩，读者应结合线上压缩再评估。
5. “像浏览器一样解析”不等于”渲染正确”。它复用 Mozilla 的解析 crate 保证了语法解析的健壮性，但 CSS 的最终表现仍取决于浏览器；降级目标的选择是否覆盖你的真实用户，需要自己用 Browserslist 数据核对。

六、优势与局限

优势：

1. Rust 原生，速度与内存占用俱佳，适合集成进 Vite/Rspack/Parcel 等快构建工具；
2. 一站式：解析、现代语法降级、自动前缀、压缩、CSS Modules 在同一个 AST 里完成，减少工具链串联；
3. 压缩产物比 CSSNano/esbuild 略小，长写转简写、calc() 化简等优化做得细；
4. 站在 Firefox 的 cssparser/selectors 之上，解析健壮性有保障；
5. CSS Modules 支持 composes 与未使用类 tree-shaking。

局限：

1. 它是 CSS 处理器/压缩器，不是完整构建系统，需要接入现有打包器才能发挥作用；
2. 相对 ESBuild 的速度优势（约 4×）远小于相对 JS 工具的（约 100×），迁移收益要看现有工具链；
3. 现代 CSS 降级虽强，但前沿语法（如非常新的选择器伪类）的覆盖仍需跟进；
4. Rust 实现意味着在纯 JS 工具链里引入原生二进制依赖，跨平台安装需要对应预编译包；
5. benchmark 样本单一（只有 Bootstrap 4），大型真实项目的收益需自行实测。

七、谁该关注

• 追求极致构建速度的团队：已经在用 Vite/Rspack、想把 CSSNano/PostCSS 这一段换掉的人；
• 需要现代 CSS 降级 + 自动前缀的人：不想手写 autoprefixer 配置、想直接写 nesting/oklab 的开发者；
• 在意产物体积的性能敏感站点：约 10% 的 CSS 体积收益在大图少、CSS 重的页面上有意义；
• 不建议：已经在用 esbuild 且对 CSS 体积不敏感的项目——迁移收益有限；以及需要 PostCSS 庞大插件生态的团队，Lightning CSS 不能直接跑 PostCSS 插件。

参考来源

• Lightning CSS 官网
• Lightning CSS GitHub（parcel-bundler/lightningcss）
• Lightning CSS 文档
• Koala 项目库条目：Lightning CSS