BEM 的 __ 和 -- 不能随意更改，因其是工具链识别和自动化处理的语法契约；改为 -element 或 _modifier 会导致 stylelint、VS Code 插件等失效，并引发样式泄漏与匹配错位。
为什么 BEM 的 __ 和 -- 不能随便改
BEM 强制用 __ 分隔元素、-- 分隔修饰符，不是为了好看，而是让 CSS 选择器可预测、可扫描、可自动化。一旦改成 -element 或 _modifier，所有基于 BEM 的工具（比如 stylelint-selector-bem-pattern、VS Code 的 BEM 插件、甚至 Webpack 的 CSS 模块化提取逻辑）都会失效或误判。
常见错误现象：.card__header--large 写成 .card-header--large，结果样式在组件复用时意外泄漏，因为 .card-header 可能被其他非 BEM 代码全局污染。
- 所有元素名必须紧跟
__，前面不能有空格或换行 - 修饰符必须用
--开头，且只能出现在块或元素之后，不能嵌套：❌.card__header--large--dark→ ✅.card__header--large+.card__header--dark - 不推荐用
_替代--，部分老版 PostCSS 插件会把下划线当单词分隔符，导致正则匹配错位
React 项目里怎么让 BEM 和 JSX 不打架
JSX 中写 className="card__header--large" 看着冗长又易错，但硬套模板字符串或函数生成反而增加维护成本。关键是把 BEM 结构“声明化”，而不是“拼接化”。
使用场景：组件需要动态组合多个修饰符，或根据 props 切换元素显隐。
立即学习“前端免费学习笔记（深入）”；
- 用
clsx而不是手写三元：className={clsx('card__header', { 'card__header--large': isLarge, 'card__header--sticky': isSticky })} - 避免在组件内定义 BEM 子类名（如
const headerClass = 'card__header'），这会让样式和结构耦合，审查 DOM 时无法一眼识别语义 - 如果用了 CSS Modules，BEM 名字要和
:local(.card__header)保持一致；否则构建后类名哈希化会破坏 BEM 的可读性
block__element--modifier 这种长名会影响性能吗
纯 CSS 层面，类名长度对渲染性能几乎没影响——浏览器解析的是选择器结构，不是字符数。真正拖慢的，是滥用嵌套选择器去“模拟” BEM，比如写 .card .card__header .card__header--large，这会让 CSS 引擎反复回溯匹配。
性能影响主要来自三处：
- 开发期：过长类名增加键盘输入和 Git diff 噪声，尤其在多人协作时容易拼错（
cardd__header这类 typo 很难被 lint 捕获） - 构建期：如果用
cssnano启用了reduceIds，超长类名可能无法被安全压缩 - 调试期：DevTools 中类名太长会自动折叠，
card__content__inner__text--highlighted看不到全貌，得 hover 才展开
建议单个类名总长控制在 40 字符内，必要时用语义缩写（card__img 而非 card__thumbnail-image），但缩写必须全团队对齐。
哪些情况不该硬套 BEM
BEM 是为“可复用 UI 组件”设计的，不是万能命名银弹。强行套用反而让代码更难理解。
典型误用场景：
- 页面级唯一区块（如
homepage-hero-banner）：没有复用需求，用语义化类名hero更轻量，加 BEM 反而显得僵硬 - 工具类（
u-text-center,visually-hidden）：这类类名本身已表达意图，BEM 会模糊其职责，变成utils__text-center就本末倒置 - CSS-in-JS 场景（如 Emotion）：
css`font-size: ${props.size}`动态样式天然隔离，再套 BEM 类名只是多一层抽象
判断标准很简单：这个样式是否会被复制粘贴到另一个组件里？如果答案是否定的，BEM 就不是必须项。
