高可维护性的自定义属性规范核心是分层清晰、命名克制、作用域明确，需经得起主题切换、组件复用、多人协作考验；应按:root（底层令牌）、组件容器（局部覆盖）、状态类（内部响应）三层收敛作用域，命名采用语义化kebab-case如--color-text-primary、--spacing-lg，所有var()必须带合法单位fallback，且:root须设默认值防失效。
直接说结论：高可维护性的自定义属性规范，核心不是“定义得多”，而是“分层清晰、命名克制、作用域明确”。它必须能经得起主题切换、组件复用、多人协作三重考验，否则很快就会退化成一堆互相覆盖的--color-1、--spacing-x2。
如何组织自定义属性的作用域层级
自定义属性不是全局变量池，它的级联和继承特性决定了你得像设计API一样设计它的作用域。错误做法是把所有值都塞进:root；正确路径是三层收敛：
-
:root只放真正跨主题、跨设备的底层令牌（如--color-primary、--spacing-unit），且全部使用kebab-case，禁用大小写混用 - 组件级容器（如
.card、.form__field）声明局部覆盖变量（如--card-shadow、--form-input-padding），仅影响内部子元素 - 状态类（如
.button--large）不直接改:root，而是在自身选择器里设置--button-height，让内部var(--button-height)自然响应
这样做的好处是：深色模式只需切换:root下的一组--color-值；组件换肤只需覆盖其容器上的局部变量；JS动态控制也只读写最靠近的父节点，不会污染全局。
为什么--spacing-sm比--s2更可维护
缩写名在初期看着省事，但三个月后没人记得--s4对应的是1.5rem还是2rem。可维护性来自语义，不是字符数：
立即学习“前端免费学习笔记（深入）”；
- 颜色类统一用
--color-{purpose}-{state}，如--color-text-primary、--color-border-disabled，不出现--c-t-p - 间距统一用
--spacing-{size}或--spacing-{direction}-{size}，如--spacing-lg、--spacing-inline-sm，避免--m2、--p8 - 字体相关必须带单位上下文，如
--font-size-h2、--font-weight-bold，而非--fs2、--fw700
这套命名法和BEM的form__input--disabled逻辑一致——人眼扫描时靠结构识别意图，而不是靠记忆映射表。
如何防止var(--x) fallback 失效导致样式崩塌
var()的回退值不是装饰，是安全绳。很多团队只写var(--color-bg)，一旦该变量未定义，浏览器会按无效值处理，可能退成transparent或initial，造成不可见的视觉断裂。
- 所有
var()调用必须带显式 fallback：background-color: var(--color-bg, #fff)，尤其在color、background、border等关键属性上 - 对数值型变量（如
--spacing），fallback 必须是合法CSS值：padding: var(--spacing, 0.5rem)，不能写var(--spacing, 8)（缺单位） - 在
:root中为所有基础变量提供默认值，哪怕只是占位：--color-text-primary: #333，避免依赖链上游缺失
这个细节在开发期几乎无感，但在主题包异步加载、CSS-in-JS动态注入、或微前端子应用样式隔离场景下，就是样式是否可用的分水岭。
最难的部分不是定义变量，而是守住边界：什么时候该加新变量，什么时候该复用旧变量；什么时候该提升到:root，什么时候该锁死在组件内。这需要定期审查变量使用率和覆盖深度，而不是堆砌文档。
