Lightning CSS 不自动 polyfill 新函数，兼容性取决于 targets 配置与源码合理性；clamp()、:has() 等特性在旧浏览器失效，因其不支持且 Lightning CSS 不降级语法结构，需手动 fallback。
Lightning CSS 本身不负责解决浏览器兼容问题，它只做转换——把现代 CSS 语法转成目标浏览器能理解的代码。能不能兼容，取决于你传给 transform 的 targets 配置和原始 CSS 写法是否合理。
为什么 transform 输出的 CSS 在旧浏览器里还是不生效？
常见现象：用了 clamp()、has() 或 color-mix()，即使设置了 targets: { chrome: 90 }，IE 或 Safari 14 仍报错或失效。
-
clamp()在 Safari ≤ 15.4 不支持，targets只控制前缀和降级（如flex→-webkit-flex），但不会自动 polyfill 新函数 -
transform不会重写语法结构，比如把:has()拆成 JS 查询，它只处理已定义的兼容性规则（如 Autoprefixer 那套） - 如果你的源 CSS 本身含 Safari 不识别的属性（如
aspect-ratio），Lightning CSS 默认不降级，除非你手动配置插件或加 fallback
怎么让 transform 真正适配老浏览器？
关键不是调用方式，而是输入内容 + targets + 后续 fallback 安排：
- 明确声明
targets，例如{ chrome: 87, firefox: 82, safari: 14.1, edge: 91 }—— 注意 Safari 版本要精确到小数点，safari: 14会被当作safari: 14.0，而 14.0 实际不支持gap在 flex 容器中 - 启用
drafts选项可解锁部分实验性转换（如logical属性转margin-left），但需确认 Lightning CSS 版本支持（v1.29+） - 对无法降级的特性（如
container-query），必须手写媒体查询 fallback，Lightning CSS 不生成替代逻辑 - 避免在
code字段里直接写@supports块——它不会被自动展开，得靠你自己写两套样式
lightningcss.win32-x64-msvc.node 报错影响浏览器兼容吗？
不影响。这个错误只出现在 Node.js 环境（如 Vite 构建时），是本地二进制模块缺失，和浏览器端运行完全无关。你在浏览器里用 import 加载 wasm/index.mjs 时，走的是 WebAssembly 路径，不依赖任何 .node 文件。
立即学习“前端免费学习笔记（深入）”；
- 如果开发时看到这个错误，说明你正在服务端或构建阶段用到了 Lightning CSS（比如 Vite 插件），此时应按 Windows 兼容方案清理
node_modules和锁文件 - 但只要浏览器端的
init()成功，transform()就能工作，和本地.node模块毫无关系 - 混淆点在于：同名库在不同环境走不同路径——Node.js 走 native binding，浏览器走 WASM，二者 ABI 不互通
真正容易被忽略的，是认为设了 targets 就万事大吉。Lightning CSS 的兼容性输出，严格受限于其内置的浏览器能力数据库（来自 caniuse），它不会猜测你想要什么 fallback，只做它知道怎么安全转换的部分。超出范围的，得你来兜底。
