Lightning CSS不是PostCSS替代品，而是定位不同的工具：它不接受插件链、不处理预处理器语法，只对标准CSS做语义级解析与压缩；想提速需提前或绕开PostCSS的活儿。
Lightning CSS 不是 PostCSS 的“替代品”，而是定位不同的工具：它不接受插件链，也不处理预处理器语法，直接对标准 CSS 做语义级解析与压缩。想靠它提速，关键不是“换掉 PostCSS”，而是把 PostCSS 的活儿提前或绕开。
为什么直接替换 css.transformer: 'lightningcss' 后构建报错？
常见错误现象：ParseError: Expected <code>{ or @、Unknown at rule @use、Unexpected token '.' in selector
根本原因：Lightning CSS 只吃标准 CSS，不吃 Sass/Less/Tailwind JIT 输出、Vue SFC 中的未编译 <style>、或含 @layer/@apply 的原始 Tailwind 源码。
- 若你用
@use或嵌套语法，必须先经postcss-nesting或 Vite 内置的css.preprocess处理成合规 CSS，再喂给 Lightning CSS - Tailwind 用户必须先运行
tailwindcss -i src/input.css -o dist/output.css生成完整 CSS，Lightning CSS 才能接手压缩 - Vue 单文件组件中，
<style lang="scss">必须由vite-plugin-sass编译后，再交由 Lightning CSS 处理；不能设transformer: 'lightningcss'同时又保留lang="scss"
在 Vite 中启用 lightningcss 的最小可行配置
不是所有配置项都需手动写，但以下三处必须显式对齐：
立即学习“前端免费学习笔记（深入）”；
-
css.transformer: 'lightningcss'—— 开启 CSS 解析/转换层替换（Vite 4.4+） -
build.cssMinify: 'lightningcss'—— 开启生产构建时的压缩（否则仍走 esbuild） -
css.lightningcss.cssModules: { auto: true }—— 若用 CSS Modules，必须用这个字段配，css.modules对 Lightning CSS 无效
示例片段：
export default defineConfig({
css: {
transformer: 'lightningcss',
lightningcss: {
cssModules: { auto: true }
}
},
build: {
cssMinify: 'lightningcss',
cssTarget: ['chrome61']
}
})注意：cssTarget 会影响前缀注入和语法降级行为，Lightning CSS 的 --browserslist 支持较弱，建议仍用 autoprefixer 做前置处理，而非依赖它自动加前缀。
遇到 calc()、var()、混合单位就失效？这是设计使然
Lightning CSS 的属性合并（如 margin-top: 10px; margin-bottom: 10px; → margin: 10px 0;）只在单位一致且语义安全时触发。一旦出现以下情况，它会跳过合并，原样保留：
-
margin: 10px 0 1em 0（px和em混用） -
width: calc(100% - 2rem)（含calc()） -
color: var(--primary)（含自定义属性）
这不是 bug，是强类型 AST 解析的必然结果。它把 margin 当作一个有明确数值域的类型节点，而非字符串拼接。想确认某条规则是否被合并？加 --source-map 输出 sourcemap，对比输入输出的 AST 结构即可。
真正卡住构建速度的，往往不是压缩本身
Lightning CSS 解析 10k 行 CSS 只需 4ms，但如果你的构建流程里还夹着：Sass 编译 → PostCSS 插件链（autoprefixer + cssnano + postcss-preset-env）→ 最后才到 Lightning CSS，那提速效果会被上游拖垮。
更合理的分工是：
- 预处理器（Sass/Less）负责变量、嵌套、混入 —— 输出标准 CSS
- PostCSS 仅保留必要插件（如
autoprefixer），关闭cssnano等压缩类插件 - Lightning CSS 接收 clean CSS，专注做语义压缩、颜色简化、空白剥离
团队协作中最难对齐的，从来不是“哪个工具更快”，而是“谁负责把语法转成标准 CSS”——Lightning CSS 越快，越容易让人忽略上游输出是否已足够规范。
