BEM修饰符不能直接控制position/top/left等布局属性，因其职责是表达状态或变体，而非接管布局逻辑；如.dialog__overlay--center错误地将模态框整体锚点意图下放到遮罩层元素，破坏语义边界与分层契约。
修饰符直接改 position / top / left 会破坏 BEM 的语义边界
BEM 修饰符的职责是表达「状态」或「变体」，不是接管布局逻辑。比如写 .dialog__overlay--center，看似让遮罩层居中，实则把「模态框整体呈现位置」这个块级意图，错误下放到 overlay 这个元素层级。结果就是：overlay 被迫承担本该由 .dialog 控制的定位职责，一旦后续加 .dialog--top-left，样式就打架——两个修饰符在争同一个元素的 position 和偏移值。
dialog__overlay--center 这类写法为什么违反 BEM 分层契约
修饰符必须依附于有明确语义边界的实体，而 dialog__overlay 的语义是“遮罩层”，它的唯一职责是覆盖、透光、拦截点击；居中、锚定、尺寸适配这些属于整个 .dialog 块的呈现意图。常见错误包括：
- 把位置控制塞进修饰符，如
.modal__content--fixed（content不决定是否固定，.modal才决定） - 用修饰符覆盖
display或float，导致元素脱离文档流后影响兄弟元素布局，但父块却无感知 - 在
card__image--rounded里写border-radius: 50%，看起来合理，但圆角其实是.card整体视觉风格的一部分，应由.card--rounded统一驱动
真正该由修饰符控制的定位相关行为有哪些
不是所有和位置有关的样式都不能进修饰符，关键看它是否属于「状态反馈」而非「布局决策」：
- ✅
.tooltip--visible：控制opacity和visibility，这是可见性状态，不改变布局流 - ✅
.dropdown__menu--open：切换transform或max-height实现展开动画，前提是菜单本身已通过.dropdown定义了锚点和定位上下文 - ❌
.dropdown__menu--top：把方向逻辑塞进元素修饰符，而不是用.dropdown--placement-top驱动整个块的data-placement和 CSS 变量
修饰符能安全介入的，仅限于「已有布局框架下的状态响应」，而不是「重建布局规则」。
立即学习“前端免费学习笔记（深入）”；
如何验证一个修饰符是否越界修改了定位
检查三点即可快速判断：
- 该修饰符是否只出现在一个块的上下文中？如果
.header__logo--sticky被复用到.footer__logo就失效，说明它本不该绑定在元素上 - 去掉这个修饰符后，元素是否仍保留在预期的文档流位置？如果移除后
margin、position、z-index全乱，说明修饰符承担了基础布局责任 - CSS 规则里是否出现了
position: absolute、inset、grid-area等脱离父容器约束的声明？这类属性应由块级类或布局工具类（如u-pos-relative）提供，而非修饰符
最危险的不是写错一行样式，而是让修饰符悄悄变成“伪布局系统”——它不会立刻报错，但会让后续任何样式调整都像在拆炸弹。
