BEM类名通过“块__元素--修饰符”结构，使类名自带语义：card__title--truncated明确标识所属模块、元素角色及当前状态，无需查HTML或CSS即可理解，实现命名即文档。
它让类名本身就能回答三个问题：这是谁的？它是什么？它现在什么状态？不用跳转文件、不用猜上下文，扫一眼就明白。
看到 card__title--truncated 就能立刻定位结构和意图
这个类名不是随机字符串，而是自带解析逻辑：card 是块（独立组件），__title 表明它是 card 的直属元素，--truncated 说明当前处于文本截断状态。开发者不需要打开 HTML 查 DOM 层级，也不用翻 CSS 文件找父选择器——命名即文档。
- 常见错误现象：写成
title-trunc或card-title-trunc，脱离 BEM 后，没人知道它属于哪个块、是否可复用、会不会和别的title冲突 - 使用场景：多人协作时，新成员 grep
card__就能捞出所有相关样式；审查 PR 时，光看类名就能判断改动是否越界 - 性能影响：无运行时开销，但显著降低认知负荷——少一次文件切换，少三秒理解时间
button--disabled 和 button__icon--hidden 的语义隔离很关键
修饰符永远只作用于它挂载的那个节点，不隐式影响子元素。这意味着 button--disabled 只负责禁用按钮整体（比如设 pointer-events: none），而 button__icon--hidden 才真正控制图标显隐。两者不能互相替代，也不能混用。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 容易踩的坑：有人在
.button--disabled .button__icon里写隐藏逻辑，这破坏了 BEM 的封装性——万一哪天button__icon换了位置或被抽成独立块，样式就失效 - 参数差异：
--disabled是行为+视觉复合状态，--hidden是纯展示控制，语义粒度不同，不能合并为button--disabled-hidden - 正确做法：JS 控制类名时，该加哪个就加哪个；CSS 中每个修饰符只声明自己节点的变更
为什么 form__field 不能简写成 field？
因为 field 是模糊词——它可能是表单里的输入框，也可能是用户资料页的只读字段，还可能是搜索结果列表里的高亮片段。只有带上块前缀，才能锁定作用域和语义边界。
立即学习“前端免费学习笔记（深入）”；
- 常见错误现象：全局定义
.field，结果表单校验样式被用户资料页的.field覆盖，排查时发现两个field根本不属于同一逻辑层 - 使用场景：当项目引入第三方 UI 库时，BEM 命名天然形成命名空间隔离，
myapp-form__field和ui-lib-field不会打架 - 一个硬约束：元素名必须语义化，
form__left这种位置描述是错的，应改为form__label或form__control
BEM 最难坚持的不是规则本身，而是拒绝“临时省事”——比如为了快一点，把 header__logo 直接塞进 nav 块里用，或者给 card__content 单独写个 card-content 类。这些缺口一旦打开，类名就从“自解释协议”退化成“需要注释才能懂的缩写”。
