子代选择器>通过严格父子关系切断深层匹配，仅匹配直接子元素，但依赖DOM结构稳定，易因结构变动失效，应结合CSS Modules或scoped样式等更可靠方案。
子代选择器 > 本身不能“防止”污染，它只是让你能精准切断匹配路径——用对了是隔离利器，用错了反而让样式更难维护。
为什么 > 能切断深层匹配
浏览器匹配 > 时，只认直接父子关系：中间插一个文本节点、注释、或任意无 class 的 <div>，整个链就断掉。它不靠类名唯一性，只看 DOM 树结构是否严格相邻。
-
.menu > .sub-menu只命中一级下拉，哪怕二级、三级也叫.sub-menu，它完全无视 - 而
.menu .sub-menu（空格）会一路穿透到所有嵌套层级，根本无法区分 - WordPress 默认生成的
<ul class="sub-menu">总是紧跟在对应<li>后面，结构稳定，>才敢用
> 容易踩的三个坑
它不是写得越深越安全，而是越深越脆弱。
- 写成
.list > .item > .content > p：DOM 稍微加个 wrapper 或换标签，样式立刻失效 - 和伪类连用如
.modal > :nth-child(2)：插入注释、条件渲染空节点，序号偏移，样式错位 - 滥用根级锚点，比如
body > div：第三方库动态挂载弹窗到body下，就会意外命中
什么时候该换其他方案
> 依赖 DOM 结构稳定，一旦结构动态性强，它就不可靠。
立即学习“前端免费学习笔记（深入）”；
- 第三方组件内改样式：用
[data-scope="editor"] .cm-line比.my-app > .editor > .cm-line更稳 - 构建环境可控：优先上
CSS Modules，类名自动哈希化，从源头杜绝冲突 - Vue/React 单文件组件：
<style scoped>自动加data-v-xxx属性，比手写>更省心
真正起作用的从来不是选择器符号本身，而是你是否清楚这个元素在 DOM 中的“物理位置”——> 只是把你对结构的理解，翻译成浏览器能执行的指令。结构一变，它就报错；结构不变，它才可靠。
