bem是解决css全局冲突与协作失控的底线规范，通过block__element--modifier结构实现样式作用域隔离、归属明确和状态语义化，并需工具链校验、目录约束与生成函数保障落地。
掌握 CSS 的 BEM 命名不是为了“显得专业”，而是当你在微前端项目里看到两个子应用同时加载 .card，结果商品卡片圆角突然变直、价格文字溢出却查不到源头时，BEM 是你唯一能立刻锁定问题模块的线索。
为什么 .btn 在协作中必然失控？
CSS 没有作用域，.btn 就是全局变量。它可能来自 reset.css、header.scss、modal 组件、第三方库，甚至某人随手写的 <div class="btn">。没人单凭类名能判断归属。
<ul>
<li>
<code>.nav__btn 明确属于导航模块，.form__submit-btn 属于表单，.carousel__control-btn 属于轮播——三者互不干扰，也不依赖 DOM 层级
user-profile__avatar 就能定位到唯一 CSS 文件；搜 .avatar 可能打开 5 个文件还不能确认上下文user-profile__ 回车即出所有元素候选，消除“想不出好名”的卡点为什么 SCSS 里的 &__element 不等于 BEM 正确？
SCSS 嵌套本身不保障 BEM 合规。很多团队写完 .card { &__header { } & a { color: blue; } }，第二行就破坏了防线。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 只允许
&__element和&--modifier两种嵌套形式；禁用& div、& a、& > span等无语义选择器 - 必须用
stylelint-selector-bem-pattern在 CI 阶段报错，而不是靠人眼检查 -
& .card__badge会编译出带空格的选择器，浏览器要回溯父节点匹配，DOM 越深越慢；&__badge才生成单类名.card__badge
为什么修饰符滥用会让状态管理变成猜谜游戏？
修饰符不是“加样式开关”，而是表达稳定、可预期的状态或变体。
-
button--primary✅（语义清晰、长期有效）；button--w-200px❌（换设计稿就得批量新增类） -
user-card__avatar--large✅（元素级修饰符，绑定在具体元素上）；avatar--large❌（脱离块，无法追溯归属） -
product-grid--two-column✅（响应式结构切换）；is-mobile❌（全局开关类一出现，@media规则就散落在十几个文件里）
BEM 最难的部分不是写对 block__element--modifier，而是让团队在加一个 tooltip 时，本能地新建 /components/tooltip/ 目录，而不是往 modal.css 里塞 .modal__tooltip——这需要目录结构契约、CI 检查、以及最初几个模块的示范性实现。
