vite中启用lightning css需同时配置css.transformer: 'lightningcss'（开发时语法转换）和build.cssminify: 'lightningcss'（构建时压缩），且node.js版本不低于18.17；它仅处理标准css，不支持sass/less等预处理器。
Lightning CSS 能显著提升构建和压缩速度，但前提是它得真正跑起来——不是装了就生效，也不是所有配置路径都等效。关键在于：选对集成方式、避开 Node.js 版本兼容陷阱、明确区分「转换」和「压缩」两个阶段。
为什么 build.cssMinify: 'lightningcss' 在 Vite 里有时没反应
Vite 4.4+ 确实支持 Lightning CSS，但仅启用 cssMinify 不够。它只管压缩，不处理语法转换（比如 nesting、custom-properties、@layer）。如果你写了嵌套 CSS 却没生效，问题大概率出在没配 css.transformer。
-
cssMinify: 'lightningcss'只在build阶段启用，开发时（vite dev）完全不触发 - 必须同时设置
css.transformer: 'lightningcss'，才能让开发服务器解析现代 CSS 语法 - 若项目用了
.scss或.less，Lightning CSS 不处理它们——它只认标准 CSS（含嵌套、@container等），预处理器仍需原有 loader - Node.js 版本低于 18.17 会报
ERR_MODULE_NOT_FOUND，因为 Lightning CSS 的 ESM 入口依赖较新的模块解析逻辑
lightningcss.transform 和 transformSync 怎么选
Node 环境下直接调用 API 时，别默认用 transform。它是异步的，返回 Promise，但在构建工具插件中常被同步上下文调用（比如 Rollup 插件的 transform 钩子要求返回字符串或对象）。强行 await 会导致阻塞或未处理 rejection。
- 构建工具插件中优先用
transformSync，它不依赖 WASM 初始化，启动快、无竞态 -
transform适合长期运行的服务（如 SSR 渲染器），能复用 WASM 实例，吞吐更高 - 两者参数基本一致，但
transformSync不支持sourceMap生成（Vite/Rspack 内部会自己补） - 传入
targets时务必用标准 browserslist 字符串，例如{ targets: '>= 0.5%, not dead' }，写成数组或对象会静默失败
Rspack 里启用 Lightning CSS 压缩的实际效果
Rspack 自带 LightningCssMinimizerRspackPlugin，但它不是开箱即用的「开关」。默认压缩强度是保守的，不启用颜色转 hex、calc 简化等深度优化，体积缩减有限。
- 必须显式传入
minifyOptions，例如：{ drafts: { nesting: true }, compress: true } - 开启
compress: true后，grid属性会被重排、gradient表达式被简化、重复声明合并——这些在 esbuild 默认压缩里全都不做 - 多线程压缩默认开启，但若构建机只有 2 核，反而可能因线程调度开销略慢于单线程；建议在 CI 中用
maxWorkers: 3锁定并发数 - 注意：Rspack 的
splitChunks会把 CSS 拆成多个 chunk，Lightning CSS 对每个 chunk 单独压缩，不会跨 chunk 合并选择器
真正快起来的关键，不是堆参数，而是确认它在哪个环节介入——是开发时的实时转换？还是构建时的最终压缩？或是 SSR 中的按需编译？漏掉任一环，都可能让你以为「没变快」，其实只是没跑对地方。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
