Lightning CSS 默认不启用压缩，必须显式配置 minify: true 并指定 targets 才生效，开发环境自动跳过，生产环境需依赖 mode: 'production' 或手动传参触发。
Lightning CSS 默认不开箱即用压缩，必须显式启用或通过构建工具集成才能生效。它不是像 cssnano 那样装完就压，而是需要明确配置「压缩入口」和「目标环境」。
Lightning CSS 压缩必须在生产环境启用
Lightning CSS 的压缩行为受环境变量或构建配置控制，开发模式下默认跳过所有压缩逻辑（包括前缀补全、calc 简化、颜色转 hex 等）。Rspack、Rsbuild 等现代工具链会自动识别 process.env.NODE_ENV === 'production' 并启用压缩，但如果你手写构建脚本或调用 transform/bundle API，则必须传入 minify: true 选项：
import { transform } from 'lightningcss';
const result = transform({
filename: 'input.css',
code: Buffer.from('body { color: red; margin: 0 0; }'),
minify: true, // ⚠️ 必须显式设为 true
targets: { chrome: 100 }, // 指定目标浏览器，影响前缀和降级
});
-
minify: true是开关，不设等于关闭压缩（即使在生产环境） -
targets影响压缩深度：例如chrome: 100允许保留color: red；若设ie: 11，则会转成#ff0000并补全所有前缀 - 未指定
targets时，Lightning CSS 使用保守默认值（类似last 2 versions），可能残留冗余前缀
Rsbuild / Rspack 中的压缩配置位置
在 Rsbuild 或 Rspack 项目中，Lightning CSS 压缩由内置插件驱动，但配置入口不在 CSS loader，而在 optimization.minimizer 或 output.css 层级：
- Rspack：需在
optimization.minimizer中显式引入LightningCssMinimizerRspackPlugin，否则即使装了 lightningcss 也不生效 - Rsbuild：默认启用，但若禁用了 CSS 处理（如自定义了
output.css为false），压缩也会被绕过 - 两者都依赖
mode: 'production'触发，mode: 'development'下插件直接不加载
常见误操作：只改了 css-loader 的 minimize 选项——这是 Webpack 时代的遗留配置，对 Rsbuild/Rspack 无效。
立即学习“前端免费学习笔记（深入）”；
压缩后 CSS 体积没变小？检查这三点
Lightning CSS 压缩率高，但实际效果取决于源码质量和配置组合：
- 源文件已手动压缩过（比如用
cssnano预处理过）：Lightning CSS 对已压缩内容优化空间极小，甚至因语法解析开销略增体积 - 启用了
sourceMap: true：source map 文件本身不压缩，且会拖慢构建；生产环境应设为false - CSS 中大量内联 SVG 或 base64 字符串：Lightning CSS 不处理这些字符串内容，它们原样保留，容易掩盖真实压缩收益
验证是否生效最直接的方式是对比构建产物中的 .css 文件大小，并用 lightningcss --dump-ast input.css 查看 AST 是否已折叠 calc、合并声明等。
真正容易被忽略的是：Lightning CSS 的压缩能力高度依赖 targets 和输入语法规范性。写一堆 margin-top: 0; margin-bottom: 0; 它能合并成 margin: 0;，但如果你写了 margin: 0 0 0 0;，它就不再动——压缩不是万能的重写器，而是基于语义安全的精简器。
