Less嵌套过深会让CSS渲染变慢，因浏览器从右往左回溯匹配选择器，如.header .nav .menu .item a:hover需逐级检查祖先，DOM越深开销越大；实测超3层后样式计算耗时升40%以上，尤其在低端安卓WebView中更明显。
为什么Less嵌套过深会让CSS渲染变慢
浏览器匹配CSS选择器是“从右往左”回溯的，.header .nav .menu .item a:hover 这种5层嵌套编译后不会被简化，而是原样输出。每匹配一个 a:hover，浏览器就得向上逐级检查祖先是否符合前四层条件——DOM树越深、节点越多，开销越大。实测显示，嵌套超3层后，样式计算耗时平均上升40%以上，尤其在低端安卓 WebView 中更明显。
常见错误现象：.card { .content { .title { color: #333; } } } 编译出的选择器是 .card .content .title，但实际只需要 .card__title 就能精准命中。
- 只对语义强关联的 BEM 组件内部嵌套，例如
.card { &__title {}, &__body {} } - 布局类（如
.row、.col）禁止嵌套，它们本就不该承担样式逻辑 - 用
lessc --lint扫描源码，自动标出嵌套 >3 层的位置
如何避免生成低效的后代选择器
Less里一个空格就决定是拼接还是后代：写 &.active 得到 .btn.active，写 & .active 却变成 .btn .active——后者是典型的低效后代选择器，浏览器必须遍历所有 .active 元素并逐个查父节点。
使用场景：下拉菜单展开时给子项加样式，容易误写成 .dropdown { & .menu-item {} }，结果污染全局。
立即学习“前端免费学习笔记（深入）”；
- 优先用 BEM 命名 + 显式类名，而非依赖嵌套推导关系
- 媒体查询别塞进深层嵌套里：
@media (max-width: 768px) { .nav { li { a {} } } }会重复输出整条父链，应提至顶层单独写 - 禁用通配符键选择器：
* {}、body * {}、.wrapper * {}在编译后仍存在，必须人工删掉
哪些CSS属性和选择器组合会拖慢渲染
box-shadow、border-radius、filter、transparency 这些不是选择器问题，而是绘制层开销；但配合低效选择器（比如 div ul li a:hover）会放大性能损失——因为匹配慢 + 绘制重，双重卡顿。
常见错误现象：混入里默认启用 will-change: box-shadow，结果所有用了该混入的元素都强制提升图层，内存暴涨。
- 用混入封装带约束的阴影：
.shadow-sm(@x: 0, @y: 1px, @blur: 2px) { box-shadow: @x @y @blur rgba(0,0,0,0.1); }，杜绝散落各处的大模糊值 - 圆角统一走变量：
@radius-md: 4px;，禁用50%或15px这类随意值 -
inset阴影慎用，尤其在滚动容器内；混入注释里必须写明：“此样式禁用于列表项”
Less变量和Mixin怎么用才不拖慢编译和运行时
变量和混入本身不参与运行时，但滥用会让编译体积失控。比如定义 20 个粒度极细的混入（.flex-justify-start、.flex-justify-center…），再在各处无节制调用，最终 CSS 可能比手写还大。
容易踩的坑：@import "variables.less" 被多个文件引用，而 variables.less 里又含 @font-face，结果每个模块都输出一遍字体声明。
- 公共变量必须加
!default：@primary-color: #007bff !default;，否则下游覆盖会失效 - Mixin 命名加前缀且参数 ≤2 个，例如
.btn-variant(@bg, @color)，别搞.btn-variant(@bg, @color, @border, @radius, @shadow) - @import 加
(reference)标记，只导入变量/混入；真正要输出的样式，用独立@import显式引入
最常被忽略的一点：Less 不会帮你判断“这个选择器是否真被 DOM 引用”。编译后搜 .btn .icon .label，如果它来自嵌套+混入双重叠加，说明抽象失控了——该砍掉一层抽象，而不是继续封装。
