BEM 解决的是 Flex 协作问题而非兼容性问题，要求容器类名绑定 Block、Modifier 表达业务意图、子项命名带上下文、响应式用静态 Modifier 控制。
Flex 布局本身兼容性已很好（Chrome 29+/Firefox 28+/Safari 6.1+/Edge 12+），但实际项目里出问题的从来不是 display: flex，而是类名语义混乱导致的样式覆盖、误复用、调试困难——BEM 不解决 Flex 的浏览器兼容，它解决的是「谁该用什么 Flex 规则」这个协作问题。
Flex 容器类名必须绑定到 Block，不能只写 flex 或 row
常见错误是定义一个全局 .flex 工具类，然后在任意容器上加它：className="flex"。结果是：某天在 card__header 里用了 .flex，后来 modal__footer 也加了，再后来发现两者 flex-direction 冲突，改一个崩另一个。
- ✅ 正确做法：每个 Flex 容器属于某个明确 Block，命名如
card__header、modal__footer，其 Flex 行为通过该类直接控制，不依赖外部工具类 - ❌ 禁止写
.flex、.flex-row这类无归属的类名；若真需抽象，应命名为u-flex（u-前缀表工具类），且只用于纯布局辅助场景（如临时对齐） - 注意：CSS Modules 或 scoped CSS 下，
.flex即使局部作用域，也因缺乏语义而难以追溯用途——你永远不知道这个flex是为了撑开卡片头，还是为了居中按钮组
justify-content 和 align-items 应由 Modifier 控制，而非元素层级硬编码
比如按钮组需要水平居中，有人会直接写 .button-group__items { justify-content: center; }。问题在于：这个居中逻辑只适用于当前组件；一旦其他 Block 也要类似布局，就只能复制粘贴或强耦合。
- ✅ 推荐方式：用 Modifier 显式表达意图，如
button-group--centered或button-group__items--centered，并在 CSS 中写.button-group--centered { justify-content: center; } - Modifier 必须可开关：删掉
--centered类，布局立刻回退到默认值，不依赖 cascade 或 fallback 规则 - 避免
--justify-between这类纯 CSS 属性映射的修饰符；应使用业务语义，如--spaced（表示子项等距分布），便于未来换为 gap 实现也不改类名
子项（Item）命名必须带 Block 上下文，禁用泛化类如 item 或 child
看到 <div class="item"></div>，你完全无法判断它属于哪个组件、是否可复用、是否允许单独渲染。Flex 子项一旦脱离容器上下文，样式极易错乱。
立即学习“前端免费学习笔记（深入）”；
- ✅ 所有子项必须用
Block__element格式，如nav__link、card__action、form__field；即使 DOM 结构相同，不同 Block 的子项也绝不共用类名 - ❌ 禁止
card__item这种模糊命名——item没有语义；应具体为card__title、card__body、card__footer - 若某子项需跨 Block 复用（如统一的
icon），应独立成新 Block：icon，而不是塞进各 Block 的 __ 命名空间里
响应式 Flex 行为要靠 Modifier 组合，别用媒体查询嵌套选择器
老写法：@media (max-width: 768px) { .card__header { flex-direction: column; } }。问题在于：这个断点逻辑被锁死在 card__header 里，无法被 modal__header 复用，也无法在 JS 中动态控制。
- ✅ 改用响应式 Modifier：
card__header--stacked-on-mobile，配合 CSS 中的@media (max-width: 768px) { .card__header--stacked-on-mobile { flex-direction: column; } } - Modifier 名称要反映行为意图，而不是设备条件；
--stacked比--mobile-column更稳定，未来加平板断点也不用改名 - 不要在 Sass/Less 里用
@include for-mobile { ... }包裹 Flex 规则——这会让类名和媒体查询脱钩，DevTools 里看不到生效条件
BEM 对 Flex 的真正价值，不是让你多写几个下划线，而是把「这个容器为什么要 flex」「这些子项为什么这样排列」这些隐含决策，变成可搜索、可组合、可删除的类名。最容易被忽略的一点：所有 Modifier 必须静态可预测——别用 JS 动态拼出 card__header--${direction}，hydration mismatch 和缓存失效都会找上门。
