不能直接用CSS变量定义原子类，因为CSS变量是运行时解析的，构建工具无法静态分析其值，导致无法Tree Shaking、破坏原子类“一个类=一条声明”的契约，且var()在非自定义属性上下文中不生效；正确做法是用:root变量管理设计Token，由工具链编译生成真实原子类。
为什么不能直接用 CSS 变量定义原子类
很多人一上来就写 :root { --mt-2: 0.5rem; }，然后在类里用 margin-top: var(--mt-2); —— 这看似模块化，实则破坏了原子类的核心价值：编译期确定、零运行时开销、可被 PurgeCSS 安全剔除。
CSS 变量是运行时解析的，构建工具（如 Tailwind、UnoCSS）无法静态分析 var(--mt-2) 对应哪个数值，也就无法判断该类是否被使用；更关键的是，它让原本“一个类 = 一条声明”的原子契约变成了“一个类 → 一个变量 → 一个值”，中间多了一层间接性，调试和压缩都变困难。
真正可行的路径是：用 CSS 变量管理设计 Token，再由工具链把 Token 编译成真实原子类。
用 :root 变量统一控制原子类的数值基准
把间距、颜色、圆角这些可配置项抽到 :root，不是为了在 HTML 里直接调用，而是供构建工具读取并生成对应原子类。例如：
立即学习“前端免费学习笔记（深入）”；
:root {
--spacing-1: 0.25rem;
--spacing-2: 0.5rem;
--spacing-4: 1rem;
--color-primary: #3b82f6;
--radius-sm: 0.125rem;
--radius-md: 0.375rem;
}像 UnoCSS 或 Tailwind 的 theme.spacing 配置，本质就是从这里或类似 JS 对象中读取数值，再批量生成 mt-2、px-4、rounded-md 这些真实类名。你改一个 --spacing-2，所有依赖它的原子类自动更新，无需手动搜替换。
- 必须确保变量名与原子类语义对齐（比如
--spacing-2对应mt-2，而不是mt-4） - 避免在
:root里定义业务色（如--header-bg），那属于组件级变量，不该进原子层 - 如果项目用 CSS Modules 或 scoped style，
:root仍需全局声明——原子类本身就必须是全局可访问的
如何让 dark:、hover: 等变体也响应变量变化
单纯靠 :root 变量无法触发伪类或媒体查询下的样式切换。正确做法是把变体逻辑交给工具链，变量只提供数值源。例如：
@media (prefers-color-scheme: dark) {
:root {
--color-primary: #2563eb;
}
}
/* UnoCSS / Tailwind 会基于这个新值，重新生成 dark:bg-blue-600 等类 */关键点在于：变体（dark:、hover:、md:）必须由工具在构建时展开为独立类名，而不是靠 CSS 变量 + :is() 或 element.style 动态计算。
-
hover:bg-blue-500是真实存在的类，不是hover:var(--bg-primary)—— 后者无效且不被任何构建工具支持 - 深色模式切换要靠 class 切换（如给
html加dark类）或媒体查询，不能只改变量值就指望样式自动重算 - 若需 JS 动态换肤，应通过切换预设的主题 class（如
theme-light/theme-dark），而非反复 setProperty
手写原子类时，哪些地方必须硬编码，不能依赖变量
如果你没用 Tailwind/UnoCSS，而是手写原子类（比如维护一个 utilities.css），以下几类声明必须写死，不能套 var()：
- 所有尺寸类：
.mt-2 { margin-top: 0.5rem; }—— 不是margin-top: var(--mt-2); - 所有颜色类：
.text-red-500 { color: #ef4444; }—— 即使你有--red-500，也不该在这里引用 - 所有响应式类：
@media (min-width: 768px) { .md:flex { display: flex; } }—— 媒体查询内不能用变量做条件 - 所有伪类规则：
.hover\:bg-gray-100:hover { background-color: #f9fafb; }
变量只用于上游配置，下游原子类必须是“所见即所得”的静态规则。否则你会在 DevTools 里看到 computed style 显示 margin-top: var(--mt-2)，而浏览器根本不会解析它——因为 var() 在非自定义属性上下文中不生效。
