BEM在CSS-in-JS中提供可读、可查、可推导的类名骨架，解决哈希类名不可调试、字符串拼接易错、重构困难等问题，核心是显式归属而非语法复古。
纯 CSS-in-JS 本身不解决命名混乱问题，反而可能放大它——css 函数返回的类名是哈希值，开发时看不到语义；而手拼字符串如 `${base}__content--loading` 又容易漏掉下划线或写错层级。BEM 的价值不在“和 CSS-in-JS 对抗”，而在给动态生成的类名提供可读、可查、可推导的骨架。
为什么 CSS-in-JS 项目里还要坚持 BEM 命名
很多人以为用了 styled-components 或 @emotion/react 就不用管类名了，结果是：调试时 DevTools 里看到一堆 css-1a2b3c，搜索不到来源；重构时改一个组件，发现 card__title 被硬编码在五个地方，漏改一处就样式错乱；新人接手后不敢动 className 字符串，怕破坏“约定”。BEM 不是复古，是给 JS 生成的类名加一层人类可读的索引。
-
css函数生成的类名不可读，但你可以用 BEM 规则命名变量：const title = css`...`;→ 类名仍哈希，但变量名title是语义锚点 - 所有 BEM 类名必须基于统一块名派生，比如
const BLOCK = 'user-card';，后续${BLOCK}__avatar、${BLOCK}--compact才能被 grep 和 IDE 全局定位 - 禁止在模板中直接拼接
className字符串，改用对象语法：className={{ [`${BLOCK}__header`]: true, [`${BLOCK}--loading`]: isLoading }}，避免空格/拼写错误
React 中 BEM + CSS-in-JS 的安全写法
手写 className={`${base}__${elem} ${base}--${mod}`} 是最大隐患：IDE 无法跳转、eslint 查不出、prettier 会格式化坏空格。真正落地的方式是把 BEM 逻辑收进工具链或封装层。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 用
clsx替代字符串拼接：className={clsx(`${BLOCK}__content`, { [`${BLOCK}__content--scrollable`]: isScrollable })} - 封装 BEM 工具函数：
const b = (block) => (element, modifier) => element ? `${block}__${element}${modifier ? `--${modifier}` : ''}` : `${block}${modifier ? `--${modifier}` : ''}`，调用时b('card')('header', 'sticky')→card__header--sticky - VS Code 配合
PostCSS Language Support插件，对__和--语法高亮，写错立刻视觉提示
BEM 在 CSS-in-JS 里最容易被忽略的边界
不是所有嵌套都该套三层。BEM 的核心是“归属显式化”，不是“字符越长越规范”。很多团队卡在“要不要给图标加 __icon”这种细节上，其实关键看它是否独立可复用。
立即学习“前端免费学习笔记（深入）”；
-
button__icon合理，因为 icon 是 button 的视觉组成部分，且不会脱离 button 单独存在 -
button__icon--filled❌ —— filled 是按钮整体状态，应由button--filled控制，内部图标颜色通过& svg继承，而非塞给元素 -
modal__header__title❌ —— header 是 modal 的元素，title 是 header 的子元素，但 BEM 不允许三层嵌套；正确是modal__title（如果 title 永远属于 modal）或拆出独立块text-block - 修饰符必须可开关：
card--hoverable✅，card--has-shadow❌（shadow 是视觉表现，应归入主题或 CSS 变量）
真正卡住人的从来不是双下划线怎么打，而是“这个状态到底属于谁”——是整个卡片，还是仅标题？是交互态，还是静态视觉变体？BEM 在 CSS-in-JS 里的作用，就是逼你把这个问题在写代码前想清楚。
