PostCSS不支持if语句等逻辑判断，仅解析转换标准CSS语法；所谓“条件类名”需通过插件预编译为静态规则，或改用JS生成CSS再交由PostCSS处理。
PostCSS里不能写if语句，别试了
PostCSS本身不支持在CSS中写if、for或变量逻辑判断——它不是模板语言，只是CSS语法的解析器和转换器。你看到的“条件类名”效果，本质是靠插件把JS逻辑提前编译进CSS，而不是运行时判断。
常见错误现象：postcss-conditionals插件报错Unknown word，或编译后啥也没变；有人试图在.btn { @if $theme == 'dark' { color: white; } }里写Sass式语法，结果PostCSS直接挂掉。
- PostCSS只认标准CSS语法（加插件扩展的有限语法），不认任何JS/TS表达式
- 所谓“条件类名”，必须转成静态输出：比如根据配置生成
.btn--primary和.btn--secondary两套规则，而非动态切换 - 如果你需要运行时响应式类名切换，该交给JS做
classList.toggle()，不是PostCSS的事
用postcss-advanced-variables + postcss-simple-vars做基础条件替换
这两个插件配合，能实现基于配置的类名前缀/后缀生成，属于最轻量的“伪条件”。适合主题切换、组件变体等预设场景。
使用场景：设计系统中要批量生成.text-primary-dark和.text-primary-light，但不想手写20个重复规则。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 在
postcss.config.js中启用postcss-simple-vars和postcss-advanced-variables - 定义变量时用
@define（不是$）：@define theme dark; @define variant primary;
- 在CSS中引用：
.text-<code>variant-theme{ color: black; } → 编译后变成.text-primary-dark - 注意：变量值只能是字符串，不能是布尔或数组；不支持嵌套判断，比如
@if嵌套@define
真正需要逻辑分支？用postcss-for + postcss-if（慎用）
这两个插件提供@for和@if语法，但它们不是标准，且维护停滞。2023年后新项目基本不推荐——容易和未来PostCSS版本冲突，调试困难。
常见错误现象：@if里用了==却忘了它是严格等于，"dark" == "DARK"返回false；或者@for循环生成的类名漏了空格，变成.btnsm而不是.btn-sm。
- 只在遗留项目中兼容旧构建流程时考虑引入
-
@if参数只能是已定义变量，不能是属性值或函数返回值 - 所有分支都会被展开为静态CSS，哪怕
@if false也会编译进去（除非用postcss-discard-comments手动删） - 性能影响小，但会让source map错乱，devtools里点不到原始
@if行
更靠谱的替代方案：用JS脚本生成CSS，再喂给PostCSS
与其在PostCSS里硬塞逻辑，不如把条件判断放在JS层——读取配置、生成规则字符串、写入临时CSS文件，最后让PostCSS处理它。可控、可debug、不依赖冷门插件。
使用场景：多租户系统中，每个客户有不同主色，需为每人生成一套theme-customerA.css。
实操建议：
- 写一个
gen-themes.js，用fs.writeFileSync拼接CSS字符串：`.btn { background: ${config.primary}; }` - 在
package.json的build脚本里加node gen-themes.js && postcss src/*.css -d dist/ - 避免在JS里拼大量CSS——用
csso或clean-css压缩输出 - 注意路径问题：
postcss命令默认不处理JS生成的临时文件，确保gen-themes.js输出到PostCSS输入目录下
复杂点在于：逻辑越强，越不该塞进CSS工具链。PostCSS的定位是“转换”，不是“编程”。类名条件的本质是数据驱动样式，这事JS比CSS更在行——别让构建工具替你做本该由应用逻辑决定的事。
