盒模型本身无命名规范，需规范的是CSS变量和BEM类名：变量须用多级语义前缀如--ui-space-padding-button-large，BEM类名须体现归属与意图，禁止原子类硬编码，确保变量与类名双向可逆映射。
盒模型本身没有“命名规范”——margin、padding、border 是 CSS 原生属性名，不能也不该重命名。真正需要规范命名的，是控制这些盒模型行为的 CSS 自定义属性（CSS 变量） 和 BEM 类名。大型项目里出问题的，从来不是写没写 margin-top，而是写了一堆 --sm、--gap、.m-2 后，没人知道哪个管按钮内边距、哪个管卡片间距、哪个在深色模式下失效。
如何给盒模型相关 CSS 变量起名
裸名 --sm 或 --gap 在大型项目中等于放弃调试权。变量必须表达“谁用、在哪用、什么维度”。
- 一级前缀锁定作用域：
--ui-space-（而非--space-），避免和--app-space-或第三方库冲突 - 二级关键词限定维度：
--ui-space-padding-vertical比--ui-padding-y更易被 IDE 补全识别，也明确区别于--ui-space-margin-block - 三级语义绑定位置与用途：
--ui-space-padding-button-large（不是--ui-button-padding-large，后者混淆了“空间”和“组件”的责任边界） - 禁用模糊值名：
--ui-space-16这类命名在换设计系统时立刻报废；应改为--ui-space-padding-button，值可变，语义不变
BEM 类名里怎么表达盒模型意图
不要用 .mt-4 或 .p-2 这类原子类直接控制盒模型——它们脱离上下文，无法追溯业务含义。BEM 类名要让人一眼看出“这个间距属于谁、为什么存在”。
- 块级容器自身带盒模型：如
.card应内置padding，对应变量--ui-space-padding-card，而不是靠.card > .card__content外部加margin - 元素级盒模型必须归属明确：
.button__icon的margin-right由--ui-space-margin-button-icon控制，不复用--ui-space-margin-small - 修饰符只表达状态变体：
.button--compact应减少内边距，但变量名仍是--ui-space-padding-button-compact，而非--ui-button-padding-compact - 禁止出现孤立盒模型类：
.mb-8这类工具类若必须存在，应统一收口为.u-mb-8并注明“仅限临时排版调试”，上线前必须替换为语义化 BEM
为什么不能用 margin/padding 直接写死数值
硬编码 margin: 12px 看似简单，实则切断了设计系统演进路径。一旦设计师把基础间距从 8/12/16 改成 6/12/18，你得 grep 全项目改三遍，还容易漏掉 calc(12px + 1em) 这种混合写法。
立即学习“前端免费学习笔记（深入）”；
- 所有盒模型数值必须走变量注入，哪怕只有一处使用，也要定义
--ui-space-margin-form-label - 变量值应在构建时统一注入（如 PostCSS 插件读取 design-tokens.json），而非人工维护多份 CSS
- fallback 必须设且有意义：
margin-bottom: var(--ui-space-margin-form-label, 12px)，IE 不支持变量时至少保底可用 - 警惕
rem/em混用：若根字体大小会动态切换（如用户缩放或主题切换），rem值需配套变量重定义，不能只靠 CSSOM 动态改font-size
最常被忽略的一点：盒模型变量和 BEM 类名之间必须形成可逆映射。看到 .search-form__input，你应该能立刻猜到它用的是 --ui-space-padding-search-form-input；反过来，看到变量名，也应该能定位到它服务的最小 BEM 单元。这种双向确定性，才是大型项目里盒模型不乱的底层保障。
