u-margin类名必须加前缀（如u-mt-4）以避免命名冲突和样式覆盖，其数值需严格映射设计系统spacing scale（如--space-4=1rem），仅用于页面级布局，禁止在组件内部使用。
u-margin类名为什么不能直接写成margin-top-4
因为没有前缀的margin-top-4会和项目里已有的margin-top、第三方库的mt-4或框架默认样式冲突，且无法通过CSS作用域隔离。BEM语境下，工具类不是“可选装饰”，而是带明确作用域的原子能力——u-前缀就是它的命名空间声明。
常见错误现象：mt-2在Tailwind项目中生效，但接入BEM组件库后突然失效；或团队成员各自定义pad-lml-8space-left，DevTools里一堆 margin 相互覆盖，根本看不出谁在起作用。
- 必须用
u-mt-1而非mt-1：前缀是隔离线，不是缩写习惯 - 数字必须对应设计系统中的 spacing scale（如 1 = 0.25rem，4 = 1rem），不映射到 xs/sm/md 等语义词
- 禁止在
u-mt-*里塞媒体查询，响应式应由独立断点前缀承担，如u-mt-2 u-mt-4@md
u-mt-1这类类名的数值怎么和设计系统对齐
数值不是拍脑袋定的，它必须映射到统一的 CSS 变量 scale，否则换主题、缩放字号、适配暗色模式时全得重写类名。比如u-mt-4背后应该是margin-top: var(--space-4)，而--space-4在:root或 theme provider 中定义为1rem。
容易踩的坑：有人把u-mt-4硬写成margin-top: 1rem，结果主题切换时--space-4变成1.25rem，但类名没变，视觉就脱节了。
立即学习“前端免费学习笔记（深入）”；
-
u-mt-*类内部只写margin-top: var(--space-*)，不写具体像素/reme - spacing scale 推荐从 0 到 8 或 12，步长保持 0.25rem 增量（0, 1, 2, 3, 4 → 0, 0.25rem, 0.5rem, 0.75rem, 1rem）
- 避免用
u-mt-half这种非数字命名——它破坏直觉，也难被 JS 动态生成（cn('u-mt-', size)就跑不通）
多个u-margin类同时使用会不会导致margin叠加失效
会，而且很隐蔽。比如u-mt-2 u-mb-4 u-mt-6一起用，最后生效的是u-mt-6（后者覆盖前者），但开发者本意可能是“顶部留2，底部留4，再加个6”——这说明类名语义和实际行为错位了。
真正的问题不在CSS，而在使用逻辑：工具类不是数值堆叠器，它是状态开关。每个u-mt-*都应代表一个明确的布局意图（如“与上一区块分隔”“紧贴标题下方”），而不是“我要加多少像素”。
- 每个方向的 margin 类只声明对应方向（
u-mt-*只设margin-top，不碰margin-bottom） - 禁止在同一元素上混用相反方向修饰符（如
u-mt-2 u-mt-4），靠 lint 工具拦截 - 高频布局组件（如
Card）提供Card_compact修饰符，主动重置所有 margin 为 0，再由父容器统一控制
u-margin类能不能用于组件内部
不能。组件内部的外边距属于布局契约的一部分，应该由使用方通过 BEM 外部修饰符控制，比如Button_margin-r或Card_margin-bottom-xxl。如果在.Button组件内部写u-mt-2，等于把布局上下文硬编码进组件，下游项目一换栅格系统就得覆盖样式甚至 fork 源码。
典型误用场景：Modal 组件内部写了u-mb-6给dialog__footer，结果在弹窗嵌套场景里 footer 下方多出一大块空白，调试时发现这个u-mb-6来自组件内部，根本没法关。
-
u-mt-*等工具类只允许出现在页面级布局容器、临时对齐、原型调试等非封装场景 - 组件块（
.c-button、.c-card）的外边距必须交由外部修饰符控制，且修饰符挂载在 block 层（.Button_margin-r），不污染 element 层 - 所有
u-mt-*类应收口在单独的spacing.css模块，禁用@import分散引入，防止构建时重复注入
u-mt-*塞进组件内部，你就已经把布局决策权悄悄交出去了。 
