Tailwind CSS 4 不识别 BEM 类名（如 card__header），因其 content 扫描器仅生成匹配原子类的 CSS，BEM 类需通过 safelist 正则显式保留，或用 @layer components + @apply 实现语义化封装。
不需要在HTML里直接写 card__header 这类BEM类名，Tailwind CSS 4 的 content 扫描器根本不识别它们——写了等于白写，构建后会被 PurgeCSS 静默删光。
为什么 card__header 在DevTools里查不到样式
Tailwind只扫描并生成它“认得”的原子类名，比如 flex、md:px-6、hover:bg-gray-50。像 card__header 或 button--disabled 这种含双下划线/双短横的命名，既不在内置白名单里，也不匹配任何默认正则，结果就是：不生成CSS、不报错、不警告，只安静消失。
- 验证方式：临时把
content: []写进tailwind.config.js，如果这时card__header突然有样式了，就确认是扫描缺失，不是语法错误 - 常见现象：
class="card__body"在浏览器里没padding、没border，打开Styles面板也找不到.card__body规则 - 根本不是bug，是设计逻辑：Tailwind打包的是“它看到且理解”的类，BEM类名不在这个范畴内
必须显式加 safelist 正则，否则上线必丢
如果你真需要保留 card__header 这类类名（比如供JS查询或E2E测试用），就得在 tailwind.config.js 里用 safelist 显式声明，不能靠“猜”或“禁用PurgeCSS”。
- 推荐正则：
/^[a-z]+(__|--)[a-z-]+$/—— 覆盖标准BEM格式，如form__input、nav--mobile - 若block名固定（如只用
user-开头），收紧为：/^user-[a-z]+(__|--)[a-z-]*$/，避免误匹配 - 别漏修饰符变体：
step__item-2或form--validating需额外补充正则，否则上线后DOM存在但样式断裂 - 绝对不要写
/card/这种宽泛匹配，可能意外保留discard、cardinal等无关词
@layer components + @apply 是唯一可控的融合路径
这不是“让BEM跑起来”，而是用Tailwind机制实现BEM意图：用语义类名承载结构分层，用原子类控制视觉表现。所有定义必须落在 @layer components 块内，否则PurgeCSS会当它是死代码删掉。
- 必须写在
@layer components里，例如：@layer components { .card__header { @apply px-6 py-4 bg-white border-b border-gray-100; } .card--compact { @apply p-2; } } -
@apply后只能接已注册的原子类（如p-4、bg-blue-500），不能嵌套调用（@apply card__header报错） - 禁止在
@apply中写原生CSS（如transform: scale(0.95)），否则脱离hover:、dark:、md:等变体支持 - BEM类名只管结构定位和测试选择器，视觉修饰（
p-4、rounded-lg）必须全交给Tailwind类，不能混写在同一元素上
BEM类名真正不可替代的场景，和最容易被忽略的坑
BEM不是为了命名而命名，它的价值在于提供组件边界、JS可感知的结构锚点、以及跨团队的语义契约。但这些价值只有在职责分明时才成立——一旦混用，问题就藏得深。
- 最常被忽略的是权重陷阱：如果
tailwind.config.js里important: true（默认是false），那么class="card__header pt-4"中的pt-4会带!important，轻松覆盖你手写的.card__header { padding-top: 1rem; }，且无任何提示 - 另一个隐形坑是责任错位：给
<div class="card__header md:flex"> 加响应式类，会让JS通过 <code>document.querySelector(".card__header")获取到的元素，在小屏下实际不满足布局预期——但JS里根本看不到md:flex - Block层（如
card、data-table）必须能独立存在，命名要小写+短横线（user-avatar✅，UserAvatar❌），不能带状态（top-banner❌，banner✅）
BEM类名是否保留，取决于你是否需要它作为组件契约的锚点；但怎么保留、在哪保留、谁负责哪部分，必须提前划清——否则上线后样式断裂、测试失败、JS逻辑失效，排查起来比重写还费劲。
