BEM规范由Yandex提出，核心是将界面拆分为块（Block）、元素（Element）、修饰符（Modifier）三层，命名格式为.block__element--modifier，强调模块独立性、语义明确性与状态可追溯性。
直接用 .btn 或 .card 写样式，很快就会在多人协作或迭代中失控——不是改不动，而是不敢动。BEM 的价值不在“看起来规范”，而在于让每个 class 名自带上下文：它属于哪个模块、扮演什么角色、当前是什么状态，三者全在名字里。
为什么 button--primary 不能 standalone 使用
BEM 中的修饰符（Modifier）必须依附于 Block，单独写 button--primary 会丢失语义锚点，导致样式被误复用或覆盖失效。比如一个弹窗里的按钮和用户列表里的操作按钮都用了 button--primary，但实际配色、圆角、阴影完全不同，却共用同一套 CSS 规则。
- 正确写法：
user-list__action-button--primary或modal-header__close-button--primary - 修饰符不表达布局或定位，
--top-left这类命名违反 BEM 原则，该交给margin或grid-area - 多个修饰符可自由组合：
button--large button--disabled是合法的，但button--large-disabled是反模式
__ 和 -- 写错一个字符，就等于没用 BEM
双下划线 __ 表示 Element（子元素），双短横 -- 表示 Modifier（修饰态）。写成单下划线 _ 或单短横 -，不仅破坏命名一致性，还会让团队成员无法快速识别层级关系，也容易和第三方库 class 冲突（如 el-button--small 是 Element Plus 自己的 BEM，你写成 button-small 就彻底失去隔离性）。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 错误：
header-logo、nav-item-active、card_content - 正确：
header__logo、nav-menu__item--active、card__content - Element 必须是 Block 的**直接子元素**，
card__content__title是非法嵌套，应拆为card__content+title__heading
第三方组件怎么套进 BEM 结构不打架
不要重写 .el-button 或 .ant-btn 的原始 class，那是自毁式维护。BEM 的解法是“包裹+穿透”：用你自己的 Block 包一层，再通过作用域限定向下控制。
立即学习“前端免费学习笔记（深入）”；
- Vue SFC 场景：
<div class="user-form"><el-button class="user-form__submit"></el-button></div>，然后写.user-form__submit ::v-deep .el-button { ... } - Shadow DOM 或纯 CSS 场景：
.user-form__submit .el-button { ... }，确保选择器只生效于该 Block 内部 - 绝对禁止：
.el-button--primary { color: red; }—— 这会污染全局，且下次升级 UI 库时大概率崩
BEM 最容易被忽略的其实是“Block 边界感”：一个 Block 必须能独立存在、有明确语义、不依赖外部结构。写到一半发现要加 __ 却卡在“这到底算不算一个 Block”，往往说明这个组件职责已经模糊了——这时候该拆，而不是硬套命名。
