后代选择器“抓太多”因 div p 匹配任意深度的 p；子选择器 .card > p 仅选直接子级 p，但需配合语义类名如 .card > .card-title 才安全可靠。
后代选择器为什么总“抓太多”
因为 div p 这类写法会匹配 div 内任意深度的 p，哪怕中间隔了 section、article、div 三层嵌套，照样生效。你本意只想改卡片标题，结果侧边栏里一个嵌套在 aside > nav > ul > li > p 里的说明文字也被染上颜色——这不是样式没写对，是选择器太贪心。
> 子选择器不是万能解药，但能砍掉一层误伤
把 .card p 换成 .card > p，就只命中 .card 的**直接子级 p**，跳过所有孙子及更深层的 p。但要注意：
-
>前后必须有空格，.card>p会被当成一个类名，完全不生效 - 它只管“嵌套深度”，不管“是不是同一类元素”——如果
.card下有多个直接子p，它依然全选 - IE6 不支持，但 2026 年绝大多数项目已无需兼容
真正稳的写法：子选择器 + 类名，缺一不可
光靠 > 还不够，得加上语义化类名才能锁定具体目标。比如：
- ❌
.card > p—— 仍可能选中卡片底部的p.description和顶部的p.status - ✅
.card > .card-title—— 只作用于带.card-title类的直接子元素，其他p完全无关
这种组合才是最小安全单元：既防深嵌套误伤，又防同级干扰。如果你用的是 Vue 或 React，还要确认该类名是在组件挂载完成后再添加的，否则 CSS 规则可能因元素暂未渲染而“看起来没生效”。
立即学习“前端免费学习笔记（深入）”；
什么时候不该用 >，而该加 class
当父容器结构本身就不稳定时，硬靠 > 锁定层级反而更脆弱。例如：
- 第三方 UI 库输出的 HTML 结构你无法控制，
.modal > .dialog可能某天被改成.modal > .wrapper > .dialog - 服务端渲染或动态插入的区块，DOM 节点可能延迟挂载，导致
.parent > .child在初始渲染时无匹配项 - 需要 JavaScript 后续操作的元素，用
document.querySelector('.card-title')比遍历.card.children找第 2 个p更可靠
真正难的不是选中元素，而是让每个类名自己就能说清“它是什么”。一旦开始写 div-2、item-first、section-inner，你就已经在用位置和顺序代替语义——那后续所有样式、JS、可访问性都得跟着 DOM 结构走，而不是跟着业务逻辑走。
