布局类必须带项目前缀，如myapp-dashboard；仅声明结构属性，禁写表现规则；业务类须语义化、无位置词；CSS加载需物理隔离，布局样式须优先加载；BEM本质是架构策略而非命名规范。
布局类必须带项目前缀，否则就是业务类冲突的导火索
不分离就等于把所有组件扔进同一个命名空间里打架。.dashboard 这种名字如果没加项目前缀，比如写成 myapp-dashboard，它和 search-form、user-card 就在同级竞争，一旦 CSS 加载顺序错位或 selector 权重拉扯，.dashboard__sidebar 的 grid-area 很可能被 .nav__item 的 margin 覆盖——这不是优先级问题，是层叠意图彻底错位。
常见错误现象：
-
.main-layout：没业务含义，复用时根本不知道它对应哪类页面 -
.container、.wrapper：只说明“它包着别的东西”，无法回答“这是什么” -
.product-grid：看着像布局，但缺项目前缀，一接入新项目就撞名
正确做法：
- 布局块名必须含项目上下文，如
myapp-dashboard、myapp-product-grid - 布局类只出现在
_layout.css这类基础层文件中，且仅声明结构（display: grid、grid-area、flex-direction） - 禁止在布局文件里写颜色、字体、
padding等表现规则
业务类不能含位置词，否则就不是业务类而是伪布局类
像 .header-search 或 .modal-button 这类名字，表面是功能组件，实际绑定了使用场景，导致无法复用。搜索逻辑不该依赖它在 header 还是弹窗里；按钮也不该因为进了 modal 就换一套样式逻辑。
立即学习“前端免费学习笔记（深入）”；
真正可复用的业务类必须回答“它做什么”，而不是“它在哪”：
-
.search-form✅：闭环功能，可插在页头、弹窗、侧边栏 -
.user-card✅：语义完整，独立交付、测试、迁移 -
.top-nav❌：位置限定，挪到 footer 就失效 -
.btn-red❌：绑定具体值，换主题就得全局替换
修饰符也得守这条线：.search-form--compact 合理（交互密度），.search-form--top-aligned 错误（位置描述）。
CSS 加载顺序必须物理隔离，不是靠命名自觉
光靠命名区分没用，加载顺序才是硬约束。布局样式必须在所有功能组件样式之前加载，否则层叠结果不可控。
推荐组织方式：
- 基础层文件统一以下划线开头：
_reset.css、_layout.css、_theme-vars.css -
_layout.css只放.myapp-dashboard、.myapp-dashboard__header这类纯结构类 - 业务组件 CSS（如
search-form.css）可引用_theme-vars.css，但绝不能@import或@use任何布局文件 - 它们之间只能靠 HTML 结构耦合，不能靠样式依赖
工具链可配 stylelint-selector-bem-pattern 检查是否出现 .myapp-dashboard .search-form 这类跨层选择器。
嵌套时类名必须平级，拼接父路径等于放弃复用
当 .user-card 出现在 .myapp-dashboard__main-content 里，CSS 类名仍是 .user-card 和 .user-card__avatar，不是 .myapp-dashboard__main-content__user-card。后者既违反 BEM 的块独立性，又让组件失去跨页面复用能力。
DOM 结构决定作用域，不是类名拼接：
<div class="myapp-dashboard__main-content"> <div class="user-card"></div> </div>
如果需要定制化样式（比如主内容区里的卡片要窄一点），加修饰符：.user-card--in-main，而不是拼路径。修饰符名也要守线：--in-main 是边界词，比 --top-aligned 好，但最好收敛为 CSS 自定义属性控制外观，避免堆叠多个 modifier。
最易被忽略的一点：BEM 不是字符串规范，是 CSS 架构策略。类名写对只是起点，真正起效的是配套的文件组织、加载顺序、以及团队对“什么是一个可复用的 UI 单元”的共识。没有这些，__ 和 -- 只是装饰。
