属性选择器嵌套会拖慢浏览器匹配速度，因其从右往左回溯时需遍历大量a节点并检查data属性，且权重飙升、覆盖困难；应改用语义类名或提级属性选择器。
属性选择器嵌套让浏览器匹配变慢
Less里写 [data-role="nav"] { a { color: blue; } } 看似简洁，但编译后生成的是 [data-role="nav"] a —— 这是个「低效选择器」。浏览器 CSS 引擎从右往左匹配，a 节点很多，引擎得逐个检查它们的父元素是否满足 [data-role="nav"]，比 .nav a 多出 DOM 属性遍历开销。
嵌套属性选择器放大权重与覆盖难度
当你在深层嵌套里用属性选择器，比如：.header { [data-state="open"] { .menu { display: block; } } }，编译结果是 .header [data-state="open"] .menu。这个选择器权重高达 0-2-1（类 ×2 + 属性 ×1），远超普通组件类 .menu-open 的 0-1-0。后续想用 .menu.is-collapsed 覆盖它，就得加更多类或用 !important —— 实际项目里这常导致样式打架。
lessc --lint 不报错，但 runtime 性能已受损
Less 编译器本身不校验属性选择器的嵌套合理性，lessc --lint 也只检查语法和变量引用，不会提示「[data-*] 嵌套超过 2 层建议拆出」。但它确实拖慢渲染：Chrome DevTools 的 **Layers** 面板里能看到这类选择器触发更频繁的样式重计算；在低端 Android 设备上，含多个嵌套属性选择器的页面首次绘制（FP）延迟可增加 80ms 以上。
替代方案：用语义类名代替属性选择器嵌套
把运行时判断逻辑交给 JS，CSS 只管呈现：
- JS 控制状态：给元素加
class="nav--open"，而不是依赖[data-state="open"] - Less 里直接写
.nav--open { .menu { display: block; } }，编译后是.nav--open .menu，权重可控、匹配更快 - 若必须保留属性驱动（如 SSR 场景），把属性选择器提级到顶层：
[data-state="open"] .nav .menu，避免嵌套生成冗余父链 - 禁用
&在属性选择器内拼接：[data-role] { &.active {} }会产出[data-role].active（合法），但[data-role] { & .active {} }产出[data-role] .active（后代，且无必要加深层级）
真正容易被忽略的不是「能不能写」，而是「写了之后谁来承担解析成本」—— 浏览器不区分你是手写还是 Less 编译出来的选择器，它只认最终字符串。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
