Lightning CSS不是PostCSS升级版，而是定位不同的Rust原生后处理器：默认全量启用安全优化（属性合并、颜色简化、去重、删注释/空白），不支持折中配置；仅处理合规CSS，不解析Sass/Tailwind指令或CSS新特性，兼容性弱于autoprefixer，需上游先转译规范。
Lightning CSS 不是 PostCSS 的“升级版”，而是定位不同的工具：它不依赖插件链，所有优化在单次 Rust 解析中完成；PostCSS 是 JavaScript 生态的 AST 管道，功能靠组合插件实现。选错角色，构建流程就容易卡死或重复处理。
Lightning CSS 默认压缩行为不可拆分
它没有 --minify 开关，也不支持“只删空格不合并属性”这类折中配置。只要执行 lightningcss CLI 或调用 transform API，以下全部生效：
- 属性合并（如
margin-top: 10px; margin-bottom: 10px;→margin: 10px 0 10px 0;，但仅限单位一致且语义合法） - 颜色值简化（
rgb(255, 0, 0)→#f00，不是正则替换，是 AST 层类型识别） - 重复规则剔除（相同选择器 + 完全相同声明块，才去重）
- 注释与空白强制剥离（除非显式加
--no-strip-comments）
PostCSS 则必须手动配 cssnano 插件，并逐项开启 mergeLonghand、reduceTransforms 等子选项——漏一个，压缩率就掉一截。
Lightning CSS 不处理非标准 CSS 输入
它只接受已转译为合规 CSS 的内容。这意味着：
立即学习“前端免费学习笔记（深入）”；
-
@use、@forward、嵌套语法（&:hover）必须由postcss-nesting或 Sass 先转成扁平 CSS - Tailwind 生成的完整 CSS 可直接喂给 Lightning CSS，但它 不运行 Tailwind 的 JIT 引擎，也不能解析
@tailwind指令 - Vue 单文件组件里的
<style>必须经vite-plugin-lightningcss或unocss预处理，不能直传 -
var(--color)、calc()、混合单位（margin: 10px 0 1em 0）会跳过合并，保持原样——这是类型安全的代价，不是 bug
Lightning CSS 的浏览器兼容性策略更激进
它的 --browserslist 支持有限，不推荐单独用于前缀补全：
- 自动加前缀能力弱于
autoprefixer，尤其对较老的 IE 特性识别不准 - 建议仍用
autoprefixer做前置处理，Lightning CSS 专注压缩和降级（如color-mix()转rgba） - 对 CSS Nesting、
:has()等新特性，它只做语法降级（转为等效旧写法），不模拟行为 - 若项目需兼容 IE11，别把它当 autoprefixer 替代品——否则
display: grid可能没前缀就上线了
真正难控的不是性能数字，而是协作边界：Lightning CSS 越快，越容易让人忽略上游是否已输出规范 CSS。比如 Sass 编译后还留着 margin: 0 auto 1em 这种三值写法，Lightning CSS 就不会合并为简写——它不纠错，只做安全优化。
