应避免CSS选择器嵌套超过三层，因其导致特异性过高、维护困难、结构脆弱、重构易失效且影响渲染性能；推荐采用语义化类名、BEM规范、属性选择器及scoped样式等方案优化。
选择器嵌套过深导致样式难以追踪
当使用类似 .header .nav .menu .item a:hover 这种 4 层以上嵌套的选择器时，实际修改一个链接悬停色，可能要翻 3 个文件才能定位到真正起作用的那条规则。浏览器 DevTools 里 hover 元素显示的匹配样式往往来自最末尾的规则，但你根本不确定是哪个父级 class 在“暗中发力”。
- 层级越深，CSS 特异性（specificity）越高，后续用
.item a覆盖它就得写更重的选择器，形成恶性循环 - 重构 DOM 结构时（比如把
.menu提升为兄弟节点），整块样式直接失效，却不会报错，只留白或错位 - 团队协作中，新人不敢动旧样式，宁可加新 class 和新规则，导致 CSS 文件持续膨胀
过度依赖元素标签名造成结构脆弱
写成 ul li a { color: #333; } 看似简洁，但只要设计改用 ol 或把导航换成 nav > a，所有链接颜色就全丢了。这种写法把样式和 HTML 标签强绑定，等于把表现层逻辑偷偷塞进了选择器里。
- 组件化开发中，一个按钮组件若依赖
button.btn-primary就比button[data-role="submit"]更稳定——前者靠 class，后者靠标签+属性，后者一旦换用a就崩 - 用
div p span em这类纯标签链，连语义都丢失了，可访问性（a11y）工具也无法识别意图
未命名或命名随意引发语义混淆
像 .red、.big、.left-20 这类“描述外观”的 class 名，在项目初期挺好用，但三个月后没人记得 .red 是指“错误提示色”还是“促销标签色”，更不知道它是否还用在按钮上。
- 搜索替换风险高：全局搜
.red改色值，可能误伤营销弹窗里的红色边框 - 无法通过 class 名反推用途，Code Review 时得逐行看 HTML 才能确认上下文
- BEM 命名如
form__submit-button--disabled虽稍长，但一眼可知作用域和状态，重构时删整块样式也不怕漏
通配符与属性选择器滥用拖慢渲染
* { box-sizing: border-box; } 看似方便，但它强制浏览器对每个节点计算一次样式，尤其在含上千节点的后台页面中，首次渲染延迟明显。而 [type="text"] 这类属性选择器，若没配合 class 使用（比如 .input[type="text"]），浏览器就得遍历全部 input 元素做匹配。
立即学习“前端免费学习笔记（深入）”；
- 现代框架（React/Vue）中，组件 scoped style 会自动加属性选择器，此时再手动写
[data-v-xxx] input[type="text"]就是双重开销 -
:not(.is-hidden) > *这类组合在滚动区域频繁重绘时，可能成为 FPS 掉帧元凶
.card {
/* 好：语义清晰、作用域明确、易覆盖 */
--card-bg: #fff;
background-color: var(--card-bg);
}
.card__header {
font-weight: 600;
}
.card__header--large {
font-size: 1.5rem;
}维护性不是靠“写得少”体现的，是靠“改得准”。一个选择器是否规范，不取决于它多短或多酷，而在于你半年后删掉它时，能否 3 秒内确认影响范围——这需要命名有约束、嵌套有节制、绑定有依据。
