Less 编译后 CSS 体积大，根本原因是默认全量展开而非按需输出：@import 会引入整个文件所有规则，--compress 仅删空格换行，真正压缩需 --clean-css 并配 --advanced，CSS Tree Shaking 需 PurgeCSS 显式配置 content 路径，嵌套与 :extend() 滥用加剧冗余。
Less 编译后 CSS 体积大，不是压缩没开，而是根本没剔除
Less 默认不做任何样式剔除——lessc 只负责展开、拼接、输出。哪怕你只用了一个 .btn-primary，只要它所在文件被 @import 进来，整个文件里所有规则（包括注释、IE hack、未调用的 mixin 展开结果）全进最终 CSS。这不是“没压好”，是“塞得太满”。
常见错误现象：lessc app.less --compress 后体积几乎不变；编译产物里出现大量重复选择器，比如 .card .header .title 和 .modal .header .title 两段几乎一样的声明；:extend() 写了但没合并，反而多出三份相同样式块。
-
--compress只删空格、换行、重复分号，对选择器合并、声明去重、未用规则删除完全无效 - 真正起效的是
--clean-css，但它必须额外安装：npm install -g less-plugin-clean-css - 命令中必须带参数才生效：
lessc app.less --clean-css="--s1 --advanced --compatibility '*'"，缺--advanced就不会合并选择器 - 若项目含中文注释或
@charset "GBK"，得加--keep-breaks，否则编码声明可能被误删
Tree Shaking 对 CSS 不是开箱即用，得靠构建层配合 PurgeCSS
Webpack、Vite 等工具原生的 Tree Shaking 只作用于 JS 模块，对 CSS/LESS 完全不感知。Less 编译后的 CSS 是“扁平字符串”，没有导出/导入语义，打包器无法判断哪些类名在 HTML 或 JS 中真实被用到。
所以真正的 CSS Tree Shaking 实际上是“按需保留”：先收集所有可能用到的类名（来自 HTML、JS、Vue/Svelte 模板），再从编译后的 CSS 中剔除未命中的规则。这靠的是 PurgeCSS 或其封装（如 tailwindcss 的 content 配置、@fullhuman/postcss-purgecss）。
- 必须显式配置扫描路径，例如：
content: ['./src/**/*.{html,js,jsx,ts,tsx,vue}'] - 避免通配符导入：
@import "components/*.less"在标准 Less 中不合法，Webpack 会静默加载全部，彻底废掉按需控制 - 慎用
@import (reference)：它不输出 CSS，但一旦某处调用了它定义的 mixin，生成的样式就一定会进包——mixin 不是“按需”，是“调用即展开” - 检查最终 CSS 是否含大量孤立规则（如只有
.sr-only { ... }却没和其它类合并），大概率是:extend()目标没真实输出，或路径错位导致继承失效
嵌套 + extend 是体积双杀，3 层以上就得重构
Less 嵌套不是语法糖，是编译时机械拼接。每深一层，选择器字符串就多一整段父级前缀；嵌套内每加一条声明，就得复制一遍完整路径。更危险的是 :extend() 在嵌套块里使用——它不会“向上合并”，而是把目标规则完整复制进当前上下文，导致同一套样式被展开多次，且无法被 --clean-css 合并。
典型症状：编译后 CSS 里出现 .page .section .card .header .title { } 和 .layout .main .card .header .title { } 这种高度相似的长选择器，中间只差一两个父类名。
- 超过 3 层嵌套（如
.card { .header { .title { ... } } }）就该警惕：体积线性增长，权重失控，AST 节点数暴增 - 把嵌套压平为 BEM 式命名：
.card-header-title，可减少 AST 节点 30%～60% -
:extend()必须满足三个硬前提才生效：目标选择器真实输出、选择器完全匹配（伪类/媒体查询要加all）、导入路径与方式完全一致（./base.less≠../shared/base.less） - 递归 mixin 若无终止条件，Less 3.9+ 会无限展开，直接触发
JavaScript heap out of memory
真正影响体积上限的，是构建流程里的“隐式全量引入”
很多人以为问题出在 Less 写法，其实更常踩的坑藏在构建配置里：一个 @import "theme/dark.less" 被 5 个组件文件各自引入，又各自调用 .icon:extend(.icon)，结果 .icon 的全部声明被复制 5 遍；或者用 vue-cli 默认配置，没启用 css.extract 或 purgecss-webpack-plugin，导致开发时的完整样式包直接进了生产环境。
最容易被忽略的一点：Less 文件体积小 ≠ 输出 CSS 体积小。一个 200 行的 button.less，若含 50 个 .btn-* 变体 + 3 层嵌套 + 2 个参数化 mixin，编译后可能产出 8KB 以上不可压缩的 CSS。
- 用
@import (once)替代普通@import控制基础类（如.clearfix）只引入一次，但路径必须字面一致 - 禁用 Webpack 的
style-loader用于生产环境——它把 CSS 注入 DOM，无法被 PurgeCSS 扫描 - 检查最终产物是否含 sourcemap：
--remove-source-maps --no-rebase必须加在--clean-css参数里，否则它会把 map 追加在 CSS 底部，体积暴涨 - 如果项目仍需支持 IE8，
--s1不能省，否则clean-css会删掉关键分号导致解析失败
真正卡住体积优化的，往往不是某个函数怎么写，而是构建链路里那些“默认行为”——比如 lessc 默认全量展开、Webpack 默认不处理 CSS 依赖、PurgeCSS 默认不扫描 Vue 模板。这些环节只要漏掉一环，前面所有 Less 层面的优化都白做。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
