BEM与原子化CSS分层混合：BEM管结构边界，原子类仅限装饰性行为，根元素禁用原子类，高频组合须封装为BEM modifier。
BEM 不是原子化 CSS 的“补充”，而是和它根本不在同一层——强行说“BEM 补充原子化”会掩盖真正要解决的问题：样式职责混乱。
为什么直接在 BEM 元素上加 mt-4 或 flex 会失控
常见错误现象是 devtools 里看到一个 button__content 元素同时挂着 button__content、px-3、py-1.5、bg-blue-600、text-white，但没人能说清哪部分属于组件逻辑，哪部分是临时调试加的补丁。
-
px-3和py-1.5如果只出现在这个元素上，就该收进button__content--compact里，而不是裸用原子类 -
flex这类布局类一旦出现，说明你本该用button__content--row或button__content--stack来表达结构意图，而不是把布局决策下放到 HTML 层 - 构建工具（如 PostCSS + PurgeCSS）可能误删掉只在 JS 动态拼接的原子类，而 BEM 类名因为写死在模板里，几乎不会被误删
真正有效的混合：BEM 定义边界，原子类只管装饰性行为
原子类只应在不改变 DOM 结构语义、不影响其他元素流式布局的前提下使用。比如 opacity-75、cursor-not-allowed、transition-all 是安全的；grid、absolute、inset-0 则不是。
- 根元素（如
modal）禁止任何原子类，只保留modal、modal--open - 子元素（如
modal__overlay）可加tw-bg-black/50，但不能加tw-fixed—— 定位应由 BEM 自身的 modifier 控制 - 高频组合（如
tw-bg-blue-600 tw-text-white tw-font-medium）必须提前封装成button--primary，否则团队里很快会出现五种写法
如何用 tailwind.config.js 防止原子类污染 BEM 语义空间
不加约束的 Tailwind 会生成上千个类，其中很多和 BEM 意图重叠（比如 rounded-lg 和 card--rounded），导致开发者无法判断该用哪个。
- 必须启用
prefix: 'tw-'，让所有原子类带前缀，从命名上区隔开：tw-flex≠flex（后者可能来自旧项目或第三方库） - 关闭
@tailwindcss/typography这类插件，除非你真有富文本编辑器需求；它生成的prose类会覆盖 BEM 组件内的排版控制权 - 在
content配置中明确限定扫描路径，避免扫描 node_modules 或 CMS 模板目录，防止误提未使用的原子类
最容易被忽略的一点：BEM 的 __ 和 -- 不是语法糖，而是强制你回答「这个样式变化是否需要被其他模块感知」——如果答案是否定的，那它就不该是 modifier，也不该用原子类临时堆砌。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
