不能。CSS选择器无运行时逻辑能力，仅能响应已存在的DOM结构和类名；:has()虽增强结构判断但受限兼容性、性能及动态内容；状态决策仍需JS或SSR提前注入。
能否用 CSS 选择器完全替代 JavaScript 状态判断
不能。CSS 选择器本身没有运行时逻辑能力，无法读取数据、执行条件分支或响应用户交互后的状态变更——它只能响应已存在的 DOM 结构和已添加的类名（如 data- 属性或伪类）。所谓“替代”，实际是把 JS 的状态决策提前到 DOM 渲染阶段，再靠 CSS 做视觉映射。
哪些状态能靠 class + 选择器安全驱动
适用于静态可预判、生命周期明确、不依赖运行时计算的状态。典型场景包括：
- 表单控件的初始校验结果（如服务端渲染后带
is-valid或is-invalid类） -
路由激活态（
.nav-link.active由框架在跳转后注入） - 折叠/展开的初始状态（
.accordion-item[open]或.panel.expanded） - 主题切换（
html[data-theme="dark"]配合 CSS 变量）
关键前提是：这些类必须由 JS（或 SSR）真实写入 DOM，CSS 仅负责“观察”和“反应”。
:has() 出现后，结构选择是否真能替代部分 JS 判断
:has() 提供了父元素基于子元素状态反向匹配的能力，但目前仍受兼容性和性能限制：
立即学习“前端免费学习笔记（深入）”；
- Chrome 105+ / Safari 15.4+ 支持，Firefox 尚未稳定启用
- 不能在
@keyframes或transition中使用 - 过度嵌套
:has(.a:has(.b:has(.c)))易触发重排性能抖动 - 无法监听动态插入的子节点（需配合
MutationObserver手动补 class）
例如：.card:has(.badge.unread) 可隐藏无未读标记的卡片，但若 badge 是 JS 异步加载的，首次渲染时该规则不生效。
容易被忽略的边界问题
三个常踩的坑：
- 伪类如
:checked、:focus-within是实时的，但它们只反映原生表单控件状态，对自定义组件（如用div模拟 checkbox）无效，必须手动同步aria-checked和类名 -
[data-status="loading"]这类属性驱动的选择器，如果 JS 忘记移除 loading 状态，UI 就永远卡住——CSS 不会帮你“超时兜底” - 用
:nth-child(2n)实现隔行变色没问题，但想“第 3 个有.error类的元素之后所有兄弟元素变灰”，纯 CSS 无法表达这种条件性兄弟选择
真正省掉 JS 的不是选择器本身，而是你愿意把状态决策权交给构建时、服务端或框架生命周期——一旦涉及异步、用户输入、跨组件联动，CSS 就得退场。
