不能用:has()替代bem修饰符，因为:has()匹配dom结构或静态状态，而bem修饰符（如.button--disabled）是js显式控制的语义开关；两者解决的问题不在同一层，:has()无法取代bem的状态管理职责。
为什么不能用 :has() 替代 BEM 修饰符？
因为 :has() 匹配的是 DOM 结构或静态状态，而 BEM 修饰符（如 .button--disabled）是 JS 显式控制的语义开关——两者解决的问题不在同一层。你无法靠 button:has(input[disabled]) 来替代 .button--disabled，除非那个 input 真实存在于 button 内部且结构固定。
常见错误现象：.card:has(.card__content--empty) 看似合理，但若 --empty 是 JS 动态加在子元素上的类，父元素样式会立即生效；可一旦 JS 没删掉这个类、或删得不干净，状态就滞留，比直接操作 .card--empty 更难调试。
-
:has()依赖真实 DOM 存在性，不是 class 列表的“语义快照” - BEM 修饰符是契约：JS 改 class → CSS 响应 → DevTools 可见可查
-
:has()的匹配结果不可见于 Elements 面板，只能靠 computed styles 推断
:has() 和 BEM 共存时哪些组合真有用？
真正能落地的场景，是那些「状态由 HTML 属性或固有 DOM 变化驱动」的地方，且不依赖 JS 控制流程。此时 :has() 能省掉一两行 class 切换逻辑，但不能取代 BEM 的状态管理职责。
-
.form-group:has(input:invalid)—— 浏览器原生校验触发，无需 JS 监听input事件再加.form-group--invalid -
.nav-item:has(.submenu[open])——<details></details>或自定义open属性切换，结构稳定、属性存在即生效 -
.card:has(img[src*="hero"])—— 根据图片 URL 特征自动打标，适合 CMS 渲染后不可控的场景
注意：:has() 内部不能写 :hover、:focus，也不能嵌套另一个 :has()；Firefox 当前（2026 年 9 月）仍不支持 :has()，需用 @supports selector(:has(*)) 包裹降级。
BEM 修饰符必须保留，但可以被 :has() 补充哪些边界？
当 BEM 的「显式状态」和 :has() 的「隐式结构信号」叠加时，能覆盖更细粒度的 UI 反馈。关键在于：BEM 控制主状态，:has() 控制子条件分支。
- 主状态由 JS 控制：
.form-field--error表示字段整体出错 - 子条件由结构决定：
.form-field--error:has(.form-field__input:invalid)可微调边框颜色，而.form-field--error:has(.form-field__input:focus)可临时移除错误提示动画 - 避免写
.form-field--error.form-field:has(...)这种冗余组合，权重高、维护难
这种写法的前提是：BEM 块名始终作为选择器起点（如 .form-field），否则 :has() 就失去作用域锚点，容易误匹配全局同名元素。
构建时 PurgeCSS 会误删 :has() 相关规则吗？
会。PurgeCSS 默认只扫描 HTML、JS 中出现的类名字符串，而 :has(.input-error) 里的 .input-error 若只出现在 CSS 文件中、未在模板里显式书写，就会被判定为“未使用”并删除。
- 必须在 PurgeCSS
safelist中加入正则，例如/\.input-error|\.form-group:has/ - 更稳妥的做法：把这类结构依赖的类名也同步写进 HTML 注释或 JS 字符串里，比如
// keep: .input-error - Vite / Next.js 等现代构建工具中，
:has()选择器本身不会被识别为“无效语法”，但内部类名仍需显式保活
最易被忽略的一点是：即使你写了 safelist，若团队成员在组件里用 className={isError ? 'form-group--error' : ''} 却忘了在 :has() 规则里对应写 .form-group--error:has(...)，那整个逻辑链就断在了 JS 层——这不是 :has() 的问题，而是契约没对齐。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
