兄弟选择器生效需满足：目标与参考元素同为父元素的直接子元素，且参考元素在前、目标在后；~匹配后续所有同级元素，+仅匹配紧邻下一个；display: none元素不参与匹配，visibility: hidden仍可匹配。
兄弟选择器怎么写才生效
必须确保目标元素和参考元素是同一个父元素的直接子元素，且参考元素在前、目标元素在后。CSS里没有“反向兄弟选择器”，~ 只能选后面的，不能选前面的。
常见错误现象：div ~ p 没生效，其实是 p 写在了 div 前面，或者中间隔了一层 wrapper 容器；又或者用了 div > p 误以为是兄弟关系。
-
~是通用兄弟选择器，匹配所有符合条件的后续同级元素 -
+是相邻兄弟选择器，只匹配紧挨着的下一个 - 如果父容器用了
display: contents，子元素会脱离文档流，兄弟关系可能失效
为什么 ~ 有时不匹配隐藏元素
它本身不关心显隐状态，但若元素被 display: none，浏览器渲染时根本不会生成对应盒模型，自然不在兄弟链中参与匹配；而 visibility: hidden 或 opacity: 0 不影响选择器作用。
使用场景：比如表单校验后显示多个提示 .error-message，想让所有后续同类提示统一变色，用 .error-trigger ~ .error-message 就比逐个加 class 更省事。
立即学习“前端免费学习笔记（深入）”；
-
display: none的元素会被完全排除在兄弟关系之外 -
visibility: hidden的元素仍参与 CSS 选择器计算 - 动态插入的元素，只要 DOM 位置满足条件，
~会立刻生效，无需 JS 干预
兼容性与性能要注意什么
~ 和 + 都是 CSS2.1 就支持的语法，IE7+ 全支持，基本不用操心兼容性。性能上，现代浏览器优化得很好，但若在超长列表（比如上千个同级 li）里频繁用 li ~ li 做样式隔离，可能触发重排或增加样式计算开销。
- 避免在深层嵌套或海量同级元素中滥用
~，尤其搭配属性选择器如[data-type] ~ [data-type] - 不要用
* ~ .target—— 通配符开头会让浏览器放弃索引优化，强制遍历 - 和
:has()混用要小心：div:has(+ p) ~ p这类组合目前仅 Chrome 105+ 支持，别当通用方案用
真实项目里容易漏掉的边界情况
兄弟选择器只看 HTML 结构顺序，不看视觉顺序。Flex 或 Grid 里用 order 调整了显示位置，但 DOM 顺序没变，~ 依然按原始顺序匹配。
另一个典型坑：注释节点、文本节点（比如换行空格）在某些解析模式下会被视为“兄弟”，但 CSS 选择器完全忽略它们——所以不用担心换行符干扰 ~ 匹配。
- Flex/Grid 的
order不影响~的匹配逻辑 - 服务器端渲染（SSR）时若模板拼接出多余空格或注释，不影响选择器，但可能干扰 JS 的
nextElementSibling - Shadow DOM 中，兄弟选择器只在同一个 shadow tree 内生效，跨 boundary 不行
事情说清了就结束
