Less本身不提升渲染性能，真正起作用的是削减选择器复杂度、消除冗余层级、剥离硬编码值；应将嵌套控制在2层内、用BEM命名替代深层后代选择器、抽离语义化变量、禁用浏览器端编译、慎用extend而优先封装混入。
直接重构老旧CSS代码时，Less本身不提升渲染性能，真正起作用的是你用它做了什么——重点是削减选择器复杂度、消除冗余层级、剥离不可复用的硬编码值。编译后的CSS才是浏览器执行的对象，Less只是帮你写得更可控。
把深层嵌套砍到2层以内
老旧CSS常靠父子关系强耦合结构，Less里写成& .child .grandchild，编译后就是.block .child .grandchild，三重后代选择器在匹配时要从右往左逐级回溯，老设备上明显卡顿。
- 遇到超过2层的嵌套（比如
&__item &__icon &::before），立刻拆成独立BEM类名：.btn__icon、.btn__icon::before - 禁止在
&内部再用&做二次嵌套，例如& { &__elem { } }——这等于主动制造4层选择器 - 用
grep -E "\.[a-z]+(\s+\.[a-z]+){3,}"扫一遍编译输出，命中即说明存在≥4个类名串联的选择器，必须处理
用变量和函数替代硬编码颜色/尺寸
老旧CSS里满屏#333、14px、2px solid #eee，不仅难维护，还导致颜色微调时要全局搜替换，极易漏改或误改，最终生成大量近似但不统一的规则。
- 把所有颜色抽成
@text-color、@border-color-light等语义化变量，统一放在_variables.less - 用
lighten(@primary-color, 10%)代替手写的#5a9bd5，确保色阶逻辑一致，且编译后仍是静态值，无运行时开销 - 间距、圆角、阴影统一用
@spacing-xs、@radius-sm等变量，避免margin: 4px 8px 4px 0这类无法复用的碎片值
删掉所有@import链式加载
老旧项目常把@import "reset.less"; @import "base.less"; @import "components/header.less";堆在入口文件顶部，Less默认按顺序同步解析，任一文件出错就中断，且无法并行加载。
立即学习“前端免费学习笔记（深入）”；
- 改用构建工具（如Webpack +
less-loader）预编译，让@import在构建期完成，不进浏览器 - HTML中只留一个
<link rel="stylesheet">引用最终CSS，禁用<link rel="stylesheet/less">这种浏览器端编译方式——它会阻塞渲染，且不支持HTTP/2多路复用 - 如果必须保留
@import调试（极少见），确保路径都是相对路径，且不跨目录深度超过2级，否则Webpack可能因resolve失败而静默忽略
用extend代替重复声明，但别滥用
老旧CSS里常见.btn { margin: 4px; padding: 8px; } .btn-primary { margin: 4px; padding: 8px; background: blue; }，这种复制粘贴式写法让CSS体积虚高。
- 用
.btn-primary:extend(.btn) {}可让编译结果合并为.btn, .btn-primary { margin: 4px; padding: 8px; }，减少字节数 - 但
extend不能跨@media或:hover作用域，比如.btn:hover:extend(.btn:active)会报错，此时必须改用混入（.hover-styles()） - 优先用混入封装逻辑，
extend只用于纯样式继承；过度依赖extend会让开发者难以追溯某条样式究竟来自哪个源文件
最易被忽略的一点：Less重构不是“把.css改成.less就完事”，而是借这个过程重新梳理样式职责边界——哪些该进_theme.less，哪些该拆成原子类，哪些其实该交给CSS Custom Properties动态控制。编译快慢不重要，关键是你是否让最终CSS的选择器更短、规则更收敛、覆盖更可控。
