less嵌套超过3层会显著拖慢css渲染，因浏览器从右往左回溯匹配，生成冗长选择器（如.header .nav .menu .item a:hover），导致匹配开销大、权重飙升、覆盖困难。
Less嵌套超过3层会显著拖慢CSS渲染
浏览器匹配选择器是“从右往左”回溯的，嵌套越深，生成的选择器字符串越长（比如 .header .nav .menu .item a:hover），匹配开销就越大。Less本身不阻止你写5层嵌套，但编译后它会原样输出冗长选择器，且权重飙升，后续覆盖困难。
- 用
lessc --lint检查源码，自动标出嵌套深度超限的位置 - 嵌套只用于语义强关联的组件内部（如
.card { &__title {}, &__body {} }），别用在布局类（.row/.col）上 - 媒体查询别塞进深层嵌套里：
@media (max-width: 768px) { .nav { li { a {} } } }会重复输出整个父链，应提出来单独写 - 空格和
&的组合极易误用：写&.active是拼接类名，写& .active就变成后代选择器——差别一个空格，结果天壤之别
box-shadow、border-radius 这些属性在Less里不能靠嵌套优化
嵌套解决不了 box-shadow 或 border-radius 的性能问题，它们是渲染层开销，跟选择器结构无关。Less能做的，是帮你更可控地限制使用范围和参数值。
- 用混入（Mixin）封装带约束的阴影：例如
.shadow-sm(@x: 0, @y: 1px, @blur: 2px) { box-shadow: @x @y @blur rgba(0,0,0,0.1); }，避免散落各处的大模糊值 - 对圆角统一用变量控制：
@radius-sm: 2px; @radius-md: 4px;，再通过border-radius: @radius-md;调用，杜绝随意写15px或50% - 慎用
inset+ 大尺寸组合，尤其在滚动容器内；混入里加注释提醒：“此样式禁用于列表项” - 不要在混入里默认启用
will-change: box-shadow—— 它该由具体动画场景触发，不是通用开关
变量和混入不是万能的，滥用反而增加编译体积
Less变量和混入确实减少手写重复，但若定义粒度过细、调用无节制，最终CSS文件可能比手写还大。关键是“复用是否真实存在”，而不是“看起来整齐”。
- 避免为单次使用定义变量：比如只在一处出现的
@btn-padding-x: 12px;，不如直接写padding: 12px 24px; - 混入带参数时，检查是否真需要动态计算：像
.flex-center(@dir: row)比直接写display: flex; justify-content: center;多一层抽象，但若项目里90%都是row，就该拆成.flex-center-row和.flex-center-col两个静态混入 - 用
@import拆分文件时，别让_variables.less变成“所有颜色/尺寸大杂烩”，按用途分：_colors.less、_spacing.less、_breakpoints.less - 编译后搜
.btn .icon .label这类选择器，如果发现它来自嵌套+混入双重叠加，就得重构——说明抽象层级失控了
昂贵属性的使用边界必须靠人工约定，Less无法自动拦截
Less编译器不会警告你“这个 filter: blur(4px) 会卡顿”，也不会阻止你在100个列表项上用 background-image: url(...)。性能底线得靠团队协作规则来守。
- 在
_mixins.less顶部加注释块，明确列出禁用场景，例如：// ❌ 禁止在 :hover 中使用 box-shadow + transform 组合动画 - 建立
_perf-rules.less文件，只放经过实测的“安全混入”，比如.shadow-safe()内部固定用1px模糊半径 - CI流程中加入 CSS 覆盖率检查：用 Chrome DevTools Coverage 面板跑关键页面，导出未使用的选择器列表，定期清理
@import的废弃模块 - 设计师给的高斯模糊图稿，前端必须转成 SVG 滤镜或静态 PNG，不能直接套
filter: blur()—— 这条得写进协作规范，Less管不了设计输入
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
