组合选择器不自动提升可读性，关键在于语义清晰、层级合理、不依赖HTML结构；后代选择器性能差且脆弱，子选择器要求结构绝对稳定，BEM下组合几乎无必要，真正需组合的是修饰符联动与伪类行为流。
直接用组合选择器本身不会自动提高可读性，关键在于是否让选择器语义清晰、层级合理、不依赖偶然的HTML结构。
后代选择器 div p 不等于“写得像 HTML”就对
很多人以为把选择器写成 .header .nav .menu .item 就是“结构清晰”，其实这是反模式。浏览器匹配是从右往左的，.item 被反复向上验证祖先节点，DOM 大时性能明显下降；更麻烦的是，一旦某层 class 名变动（比如 .menu 改成 .dropdown），整条规则就失效。
- 只在子元素样式**强依赖父容器上下文**时才用后代选择器，例如：
.modal .close-btn—— 关闭按钮只在模态框内有特殊定位和 z-index - 删掉外层选择器后，内部规则是否还成立？如果
.close-btn单独存在本该有默认颜色和尺寸，那就不该靠.modal .close-btn定义基础样式 - 避免用
body header nav ul li a这类“结构复刻”，它既冗余又脆弱，应拆成.main-nav a+.main-nav a:hover
> 子选择器适合结构绝对稳定的父子关系
> 比空格更严格，也更快 —— 浏览器只需检查直接父级，不用遍历整个祖先链。但它要求 HTML 结构铁板一块，稍有嵌套变化就会断。
- 适用场景：组件封装明确、不允许子元素被包裹的场景，如
.dropdown > .menu > .item，其中.menu必须是.dropdown的直接子元素 - 不适用于泛用容器，比如
.card > .title—— 如果未来卡片里加个<div class="card-body">包一层，样式立刻失效 - 搭配 BEM 时慎用：
.card__body > .card__title是多余设计，BEM 本意就是靠类名自洽，不需要靠层级限定
BEM 命名下组合选择器几乎没存在必要
当你用 .search-form__input 和 .search-form__submit 这类命名时，每个 class 都自带作用域和语义，再写 .search-form .search-form__input 纯属画蛇添足。
立即学习“前端免费学习笔记（深入）”；
- BEM 的核心是“类名即含义”，
.search-form__input--error已表明状态和归属，无需靠父级 class 锁定作用域 - 混用 BEM 和嵌套会破坏隔离性：一旦抽离
.search-form组件到其他页面，嵌套规则可能意外影响全局.search-form__input - 真正需要组合的地方，其实是修饰符联动，比如：
.search-form--compact .search-form__input—— 这里.search-form--compact是 block 级状态，影响子元素布局，属于合理组合
伪类与伪元素组合要明确意图，别堆砌
a:hover:focus 和 a:focus:hover 渲染结果一样，但前者语义更准：先有悬停，再获得焦点（比如用键盘 tab 进入已 hover 的链接）；而后者逻辑反了。
- 伪类顺序建议按用户行为流排列：
:link → :visited → :hover → :focus → :active（LVHFA），虽然 CSS 规范不强制，但能降低团队理解成本 - 避免无意义叠加，比如
.btn:enabled:hover:valid——:valid对 button 无效，纯属干扰阅读 - 用
&在预处理器中生成复合状态更安全：.btn { &:hover:not(:disabled) { … } }，比手写.btn:hover:not(:disabled)更易维护
真正拖慢可读性的不是选择器多长，而是你得反复翻 HTML 才能确认某条规则到底生效在哪一层。与其靠嵌套或组合“模拟结构”，不如用命名表达意图、用类名承担语义责任 —— 这才是可读性的根子。
