css选择器无法选中“前面的兄弟”是因为规范禁止反向遍历dom树，~和+仅匹配后续同级元素；:has()是唯一可行的向上感知替代方案，需写在被影响元素上。
为什么 CSS 选择器无法选中“前面的兄弟”
CSS 选择器根本不存在“向前查找”的能力，~ 和 + 都只匹配当前元素之后的同级节点，对它之前的兄弟元素完全无感知。这不是浏览器兼容问题，而是 CSS 规范从诞生起就明确禁止反向遍历 DOM 树——因为这会破坏样式计算的单向性与性能模型。
通用兄弟选择器 ~ 的实际作用范围
~ 看起来“宽松”，但它仍严格受限于文档流顺序和层级关系：
- 必须是同一父元素的直接子元素，嵌套一层就会断链（比如
.wrapper > .input ~ .hint中，如果.hint在.wrapper外，就完全不匹配） - 参考元素（如
input:checked）必须在 HTML 中物理出现在目标元素之前，哪怕中间只有一个换行符生成的#text节点，~仍能工作，但+就会失效 -
display: none的元素会被彻底排除在兄弟关系之外；而visibility: hidden或opacity: 0不影响选择器匹配
:has() 是目前唯一可行的“向上感知”替代方案
:has() 不是父选择器，但它能让祖先或同级前置元素“响应”后代/后续元素的状态。例如想让某个 .header 在它后面某个 .cell.open 出现时变色，就得写成：
.header:has(~ .cell.open) {
background: #ffe;
}
注意几个关键点：
-
:has()必须写在“被影响”的元素上，不能写在触发元素上 - 内部用
~或+是为了描述“相对位置关系”，不是为了选中它们本身 - Chrome 105+、Firefox 121+、Safari 15.4+ 支持，但旧版 Safari（如 15.3 及更早）不支持
-
:has(.open)和:has(~ .open)完全不同：前者只要子元素有.open就触发，后者要求.open是它的后续兄弟
真正容易被忽略的底层事实
很多人调试半天发现 input:checked ~ .panel 不生效，最后发现 .panel 其实被包在了另一个 div 里——它压根就不是 input 的兄弟，而是“侄子”。DOM 结构比选择器语法更决定成败。打开开发者工具，逐层确认节点是否真同级、是否真在后面、是否被 display: contents 或框架注入的注释节点悄悄打断，比反复改选择器更有效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
