该用 tab__item--active 而不是 is-active：当活跃状态在服务端或模板层确定时，--active 是 BEM 原生修饰符，CSS 独立生效、PurgeCSS 可识别、DevTools 易追踪；is-active 必须与块/元素名组合使用，不可单独定义，否则导致样式泄漏或工具链失效。
什么时候该用 tab__item--active 而不是 is-active
当组件的“活跃”状态在服务端或模板层就能确定（比如路由匹配出当前导航项），就该用 tab__item--active。它代表设计契约中的固有变体，不是运行时临时状态。
-
--active是 BEM 原生修饰符，CSS 可独立生效，JS 失败也不影响视觉反馈 - 它能被 PurgeCSS 正确识别——只要 HTML 里写了
tab__item--active，就不会被误删 - DevTools 里一眼可见状态归属，不用猜这个
is-active到底属于哪个块 - 错误写法：
tab__item is-active（两个分离 class），但 CSS 规则只写了.tab__item--active，样式完全不生效
is-active 必须和块/元素名一起出现，不能单独写 .is-active
单独定义 .is-active { display: block; } 是危险操作：它会全局生效，让 .tooltip.is-active、.sidebar.is-active 全部强制显示，甚至覆盖动画属性。
- 正确写法只有：
.tab__panel.is-active、.user-card.is-loading - 这样既隔离作用域，也确保构建工具（如 Tailwind 的 content 扫描）能识别真实使用痕迹
- 如果 JS 动态添加
is-active，但 HTML 模板没出现对应组合，PurgeCSS 可能直接删掉这条规则 - 屏幕阅读器不认
is-active，必须配aria-current="page"或aria-selected="true"
为什么不能混用 btn--primary.is-active
这不是语义叠加，而是逻辑污染。--primary 是设计层面的主题修饰符，is-active 是运行时状态信号，二者生命周期、控制方、维护责任完全不同。
- BEM 要求修饰符平级且正交：
btn--primary、btn--disabled、btn--loading各自完整声明样式，互不依赖 - 混写
btn--primary.is-active会让 CSS 权重失控，也违背 “一个类名表达一个意图” 的原则 - JS 切换时容易漏掉同步逻辑，比如加了
is-active却忘了移除btn--disabled - 工具链（如 PostCSS BEM 插件）无法校验这种非标准组合，长期会演变成命名黑洞
-- 是唯一合法修饰符分隔符，别用 - 或 _
写成 btn-disabled 或 btn_disabled 看似省事，实则破坏 BEM 的可解析性与工具链兼容性。
-
btn--disabled✅ 被识别为「btn 块的 disabled 状态」，PurgeCSS 匹配btn--*模式安全保留 -
btn-disabled❌ 被当成新块名，DevTools 里看不出和 btn 的关系，团队协作时易误解 -
btn_disabled❌ 下划线无 BEM 约定，自动化检查工具直接报错或忽略 - JS 用
classList.toggle()切换最稳，避免手动拼字符串导致空格遗漏或类名覆盖
实际项目里最容易被忽略的，是把 is- 类当通用开关来用，却没在 CSS 中为每个具体上下文写全限定选择器。一旦漏掉 .nav__link.is-active 这种组合规则，光靠 .is-active 就会引发样式泄漏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
