使用 .parent:hover .child 可在父元素悬停时修改任意嵌套层级的子元素样式；误用 > 仅匹配直接子元素，+ 则为兄弟选择器；需注意移动端 hover 不可靠、伪类顺序（lvha）及性能问题。
父元素:hover时修改子元素样式，用空格分隔就行
直接写 .parent:hover .child 就行，中间的空格表示后代选择器（descendant combinator），不是子代（>）也不是相邻（+）。只要 .child 在 .parent 内任意嵌套层级，鼠标悬停在 .parent 上就会触发。
常见错误是误用 >：比如写成 .parent:hover > .child，这要求 .child 必须是 .parent 的**直接子元素**，如果中间隔了一层 div 或 span 就不生效。
-
.parent:hover .child→ ✅ 任意后代都匹配 -
.parent:hover > .child→ ⚠️ 只匹配直接子元素 -
.parent:hover + .child→ ❌ 这是兄弟选择器，和子元素无关
:hover作用域只限于被悬停的元素及其后代
注意 :hover 的“作用域”不会穿透到父级或同级。例如：.grandparent .parent:hover .child 是合法的，但 .parent:hover .sibling .child 不会因为 .parent 悬停就影响 .sibling 下的 .child —— 除非 .sibling 本身也在 .parent 内部。
典型陷阱：想让悬停父容器时高亮「另一个平行模块」，这是 css 做不到的，必须借助 js 监听事件并手动加 class。
立即学习“前端免费学习笔记（深入）”；
- 支持：悬停
.nav→ 改变.nav .dropdown - 不支持：悬停
.nav→ 改变.header .logo（除非两者有祖先-后代关系） - 性能提示：避免写太深的后代选择器，如
.a .b .c .d .e:hover .f，重绘开销大且难维护
移动端 hover 不可靠，需额外考虑触摸行为
在 ios 和 android 大部分浏览器中，:hover 仅在模拟桌面模式（如 chrome DevTools 切换 device mode 并启用 hover）下有效；真机上首次点击可能触发一次 hover，之后立即失效。这不是 bug，是规范行为。
如果交互逻辑依赖悬停反馈（比如下拉菜单、工具提示），必须提供 fallback：
- 用
:focus-within替代部分场景（例如表单区域悬停/聚焦时展开提示） - 对关键操作，用 JS 绑定
touchstart+click并切换 class - CSS 中可同时写
.parent:hover .child, .parent.focus .child，再用 JS 控制.focus类
伪类顺序影响是否生效：:hover 必须放在 :link/:visited 之后
如果你在给 <a></a> 标签写悬停样式，顺序错了会导致 :hover 完全不生效。标准 LVHA 顺序必须是：:link → :visited → :hover → :active。
例如这段会失败：
a:hover { color: red; } a:link { color: blue; }因为 :link 覆盖了 :hover。正确写法是：
a:link, a:visited { color: blue; } a:hover { color: red; } a:active { color: orange; }纯 class 选择器（如 .btn:hover）不受此限制，但混用锚点伪类时务必检查顺序。
CSS 的父子 hover 控制本质就是“状态传播”，它不改变 dom 结构，也不触发重排，但容易因层级理解偏差或设备特性翻车。最常被忽略的是移动端无 hover 和伪类顺序这两个点，上线前最好在真机上点一点验证。