为什么 @import 不适合管理 spacing 规范
因为 @import 是同步阻塞加载，会拖慢 CSS 解析，且无法被现代构建工具（如 Webpack、Vite）有效提取或复用。更关键的是：它不支持条件引入、变量注入或作用域隔离，一旦多个模块都 @import 同一份 spacing.css，就可能引发重复声明、覆盖冲突或 cascade 意外。
常见错误现象：margin-bottom: var(--space-md); 生效但实际值是 undefined；或者两个组件引入同一份 spacing 文件后，--space-lg 被后加载的样式悄悄改成了不同值。
- 使用场景：仅适用于纯静态 HTML + 无构建流程的老项目，且全站只有一处引入
- 性能影响：每个
@import都触发一次 HTTP 请求（未开启 HTTP/2 时尤为明显） - 兼容性影响：IE 中嵌套
@import层级超过 3 层可能失效
CSS 自定义属性 + :root 是更稳的 spacing 管理方式
把间距定义为 CSS 自定义属性，挂载在 :root，所有组件直接消费变量，无需重复引入文件。构建工具能天然识别并内联、压缩、tree-shake（如果用 PostCSS 插件）。
示例：
:root {
--space-xs: 4px;
--space-sm: 8px;
--space-md: 12px;
--space-lg: 16px;
--space-xl: 24px;
}
- 变量名必须统一前缀（如
--space-），避免和第三方库冲突 - 数值推荐用
px，不用rem或em—— spacing 是设计系统原子单位，不该受字体缩放影响 - 不要在
:root里写媒体查询来动态改 spacing 值，响应式应由组件自身控制（比如加@media (min-width: 768px)切换 class）
如何让 spacing 可维护又不污染全局
直接往 :root 写一堆 --space-* 看似简单，但团队协作时容易误删、重命名不一致、缺乏文档。真正可持续的做法是：把 spacing 定义抽成独立 CSS 文件，再通过构建工具「注入」而非 @import 引入。
立即学习“前端免费学习笔记（深入）”；
- 路径建议：放在
src/styles/tokens/spacing.css，和 color、radius 等其他 design token 并列 - 构建阶段用插件（如 PostCSS-import 或 Vite 的
css.preprocessorOptions）自动前置注入，确保它永远在最前面 - 配合 lint 工具（如 stylelint-config-standard）校验是否用了未定义的 spacing 变量，例如报错
Unknown custom property '--space-xxl'
组件中用 spacing 的正确姿势
别在组件样式里硬写像素值，也别用 @import 单独拉 spacing；而是直接引用已声明的自定义属性，并配合理解其语义边界。
示例：
.card {
padding: var(--space-md) var(--space-lg);
}
<p>.button-group > <em> + </em> {
margin-left: var(--space-sm);
}
- 避免组合混乱：不要混用
--space-md和8px在同一组件里 - 注意盒模型：
margin和padding都可用 spacing 变量，但gap更推荐——它天然支持 flex/grid，且不会触发 margin collapse - 慎用负 spacing：如
margin-left: calc(var(--space-sm) * -1)，虽然可行，但会让设计系统语义断裂，应优先考虑用gap或 wrapper 重构布局
事情说清了就结束。真正的难点不在定义几个变量，而在于让所有人——设计师、前端、新来的同事——默认知道 --space-lg 就是 16px，且这个认知不依赖某次 @import 是否成功执行。
