Less 编译产物体积大源于重复导入、深层嵌套、未压缩输出和 mixins 无节制展开四类问题；需通过 @import (once)、扁平化嵌套、clean-css 压缩、按需拆分入口等手段控制编译行为。
Less 编译产物体积大，不是因为语法本身臃肿，而是编译时重复导入、深层嵌套、未压缩输出、mixins 被无节制展开这四类问题叠加导致的。解决它不靠“删代码”，而靠控制编译行为和组织方式。
@import (once) 必须显式写，否则重复引入直接翻倍体积
Less 不会自动去重 —— @import "variables.less" 出现 3 次，就输出 3 份变量生成的 CSS（哪怕实际没用到任何变量）。常见于组件库混用、多层 @import 嵌套场景。
- 所有公共文件（
variables.less、mixins.less）必须加@import (once)，不能省略括号 -
(once)只对**完全相同路径**生效：@import (once) "./mixins"和@import (once) "../shared/mixins"仍会被视为两个文件 - 禁用通配符导入：
@import "components/*.less"不仅多数 Less 版本不支持，还会破坏依赖顺序，引发样式错位 - 构建时开启
strictImports: true（less-loader 或命令行），让缺失文件立刻报错，而不是静默跳过导致部分样式丢失
嵌套超过两层就该用 &-modifier 扁平化输出
三层嵌套如 .card { .header { h1 { color: red; } } } 会生成 .card .header h1，不仅 specificity 高、难覆盖，gzip 压缩率也低。Less 的 & 是控制输出结构的关键工具，不是装饰。
- 优先用
&-header、&-body这类写法，编译后只生成.card-header、.card-body等扁平类名 - 避免在
@media块内深层嵌套，它会让整个媒体查询包裹一堆冗余选择器；改用.card@media-md { }配合:extend()更可控 -
:extend()在跨模块复用时容易失控（比如一个.clearfix被 extend 十次，生成十组组合选择器），高频原子样式（阴影、过渡）用.shadow-sm()mixins 更稳妥
--clean-css 不等于 --compress，参数错配反而增大体积
lessc --compress 只删空格换行，适合本地调试；lessc --clean-css 需额外装 clean-css-cli，能合并选择器、简化单位、转简写色值，但默认行为可能适得其反。
立即学习“前端免费学习笔记（深入）”；
- 加
--remove-source-maps和--no-rebase，否则 sourcemap 会附在 CSS 底部，单文件涨几十 KB - 输入 Less 文件里若有大量
// 行注释，clean-css 会原样保留（它只删/* */），导致体积虚高 - CI/CD 流水线建议用
--clean-css+--compatibility "*"，本地开发用--compress更安全 - Webpack 用户应把压缩交给
css-minimizer-webpack-plugin，而非依赖 less-loader 的压缩选项，确保 PostCSS 插件（如 cssnano）能在 CSS 生成后介入
Less 本身不支持 Tree Shaking，按需加载得靠构建拆分
Less 是预处理器，没有运行时能力。所谓“只编译用到的样式”，本质是“只让构建工具打包被引用的 Less 入口”。把所有样式塞进一个 app.less，再怎么优化都白搭。
- 按路由或功能域建独立入口：
route-profile.less、widget-chart.less，每个只@import自己需要的部分 - Webpack 中用
import('./styles/route-profile.less')动态加载，配合mini-css-extract-plugin提取为单独 CSS 文件 -
@font-face、@keyframes这类全局规则，禁止放在variables.less里，应抽成base/fonts.less并由主入口唯一引入 - 变量定义必须前置，且不能被后续同名定义覆盖；调试时可在末尾加
.debug { color: @primary-color; }快速验证是否生效
真正卡住体积的，往往不是某条规则写得多，而是 @import 路径写错一次、嵌套多了一层、或者忘了关 sourcemap —— 这些细节在本地看不出来，上线后 gzip 前体积可能差两三倍。
