bem类名在动态插入dom时未生效，因css静态解析不扫描新节点；需确保样式提前加载、用classlist.add()操作类名、严格遵循块-元素-修饰符层级规范，并避免js拼接类名导致的断层。
动态插入的DOM节点为什么BEM类名没生效
因为CSS是静态解析的，浏览器不会重新扫描新插入的节点去匹配已有样式规则。BEM类名本身不带逻辑，只是命名约定，block__element--modifier 写得再规范，如果对应CSS选择器没加载或没覆盖到新节点，照样不生效。
- 确保动态插入前，相关BEM CSS已通过
<link>加载或style标签注入，而不是依赖JS运行时才生成样式 - 避免用JS拼接class字符串硬编码BEM结构（如
el.className = 'card__header card__header--large'），容易漏掉状态、拼错双下划线；改用classList.add()分步控制：el.classList.add('card__header', 'card__header--large') - 若用模板引擎（如Handlebars、Lit）或框架（React/Vue），BEM类名应由渲染逻辑统一生成，而非在CSS里靠后代选择器“碰运气”匹配
用document.createElement + BEM时class怎么写才不容易出错
BEM不是语法糖，是约束——类名必须严格对应语义层级，否则.menu__item.is-active和.menu-item.is-active在CSS里就是两个世界。
- 块名（block）必须明确：不要用
list这种泛称，优先用业务上下文名，如product-list；否则多个模块共用list__item会互相污染 - 元素（element）不能嵌套：禁止
product-list__item__price，价格属于product-list__item的子元素，应写作product-list__price并确保它直属于product-list作用域 - 修饰符（modifier）只用于开关状态：比如
product-list--grid表示布局切换，但不要用--loading控制显隐——那是JS职责，CSS只需提供.is-loading这类中性状态类，由JS增删
React组件里用BEM，clsx和classnames哪个更适配
两者都行，但clsx更轻、API更直觉，且对BEM的条件组合更友好——尤其处理block__elem--mod这种带连字符的动态类名时不易出引号错误。
- 别把BEM类名拆成多段字符串再拼：
`${block}__${elem} ${block}__${elem}--${mod}`，易错且难维护；用clsx对象写法更稳：clsx(`${block}__${elem}`, { [`${block}__${elem}--${mod}`]: isActive }) - 避免在JSX里写深层嵌套BEM：比如
<div classname="card"><div classname="card__body"><div classname="card__body__title">——<code>card__body__title违反BEM原则，应改为card__title - 如果组件支持主题/变体，把修饰符提取为prop，而不是在CSS里写
.card--dark .card__title这种强耦合后代选择器；用card--dark card__title平级类更可控 - 若项目已重度依赖BEM，可在
styled组件内保留块名作为根类（如const Card = styled.div.attrs({ className: 'card' })），但内部元素改用语义化本地类名：header、footer，靠CSS-in-JS的作用域天然隔离 - 不要用BEM修饰符去驱动CSS-in-JS逻辑，比如
css`${card}--hovered { ... }`——hover状态应由:hover伪类处理，不是靠JS增删类名 - 真正需要BEM的地方只剩跨组件复用的原子类（如
text--sm、space-y-2），这类工具类可单独抽离为CSS文件，不走CSS-in-JS流程
CSS-in-JS方案（如Emotion）还能用BEM吗
能，但意义变了——BEM从“避免样式冲突”退化为“团队命名共识”，因为CSS-in-JS默认作用域隔离。强行套BEM反而增加冗余，比如css`&__header { ... }`在Emotion里既难读又无实际封装价值。
user-card__avatar--large，但CSS里只有.user-card__avatar，或者写了--large却忘了定义font-size。这种断层比命名不规范更致命。
