真正过滤嵌套标签应优先用子选择器 > 限定层级，配合bem命名或属性选择器（如 [data-role=”tab”]）解耦dom结构依赖，避免后代选择器 .a .b 的意外捕获。
复合选择器怎么写才真正过滤到嵌套标签
直接用 .container .item 这种空格分隔的后代选择器，看似能匹配嵌套结构，但实际会命中所有层级的 .item，哪怕它在子组件、弹窗、第三方库里——这不是“过滤”，是“撒网”。真要限定“只作用于某一层级的嵌套”，得靠选择器的结构表达力，而不是靠猜 DOM 深度。
关键不是“能不能写”，而是“写了之后是否如你所想地生效”。比如 .card > .content 只匹配直接子元素，.modal .dialog .close 会穿透多层但无法区分是同一组件内还是被其他模块污染的 .close。
- 优先用
>（子选择器）代替空格（后代选择器），避免意外捕获深层嵌套 - 组件级样式建议加唯一前缀，比如
.user-profile__header，比.profile .header更可控 - 慎用
:nth-child()或:first-of-type做嵌套过滤——DOM 结构一变就失效，它不看语义，只数标签
伪类和属性选择器能替代嵌套逻辑吗
不能直接替代，但能补位。比如你想“只给有 data-role="tab" 的 .nav-item 加边框”，写成 .nav-item[data-role="tab"] 比硬凑 .tabs .nav-item 更可靠——它不依赖父容器是否存在，也不怕父类名被复用。
常见误用是把 :hover 当嵌套条件：.menu:hover .submenu 看似合理，但一旦 .submenu 是通过 js 动态挂载到 body 下（比如 antd 的 Dropdown），这个选择器就完全失效。
立即学习“前端免费学习笔记（深入）”；
-
[data-*属性选择器适合标记“用途”，比纯 class 更不易冲突 -
:is()和:where()可简化多层嵌套写法，但注意:where()会重置优先级，可能让样式被意外覆盖 -
:has()能反向表达“父元素满足子条件”，但目前仅 chrome 105+ 和 safari 15.4+ 支持，生产环境慎用
为什么 BEM 命名比嵌套选择器更靠谱
因为 BEM 把嵌套关系“拍平”进 class 名，绕开了 css 选择器对 DOM 结构的强依赖。写 .button--primary 不需要关心它是不是在 .form 里，也不怕父级加了 .theme-dark 就让按钮变色失控。
很多人以为 BEM 是“为了命名规范”，其实是为了解耦样式作用域。嵌套选择器越深，越容易在重构时牵一发而动全身——改个父容器 class，十处样式全崩。
- BEM 的
__表示元素，--表示修饰符，全部是单 class，无依赖 - 不用
.sidebar .sidebar-header .sidebar-title，直接用.sidebar__title - 如果必须用嵌套（比如第三方组件定制），用
:is(.react-component) > .content显式声明作用边界
CSS-in-JS 和 scoped style 怎么影响嵌套过滤逻辑
它们本质是绕过“CSS 全局性”这个老问题，不是优化嵌套写法。Vue 的 <style scoped></style> 编译后会给每个 class 加唯一 data 属性，比如 .btn[data-v-f3f2b1]，此时写 .btn > .icon 实际变成 .btn[data-v-f3f2b1] > .icon[data-v-f3f2b1]——它强制要求父子都带相同 hash，等于隐式绑定了嵌套层级。
但这也带来新坑：如果子组件没用 scoped，或者用了 <style></style> 全局块，那个 .icon 就不会被 hash，导致样式丢失。
- scoped style 下，
>仍有效，但空格选择器可能因 hash 不一致而失效 - CSS-in-JS（如 styled-components）中，
& > span这种写法是安全的，因为编译时已知父级生成的 class - 不要在 scoped 或 CSS-in-JS 中混用全局 class 做嵌套，比如
.el-input > input，它大概率不工作
嵌套过滤真正的复杂点不在语法，而在你是否清楚“这个样式到底该由谁负责”。DOM 结构会变，组件会被复用，第三方库会升级——靠选择器深度锁死样式，不如靠命名约定和作用域隔离来得稳。