Less编译后CSS缩进混乱是因为lessc默认不控制格式，仅忠实反射源文件空白字符；需用prettier或postcss等外部工具统一格式化，而非依赖Less自身修复。
Less 编译后 CSS 缩进混乱，不是编译器“格式错乱”，而是它根本不管缩进——lessc 默认输出的是语义等价、无格式的 CSS 字节流，所谓“缩进”只来自你源文件里的换行和空格，以及嵌套块的自然换行。压缩或美化必须靠外部工具介入，不能指望 Less 自身修复。
为什么 lessc 不控制缩进？
Less 的设计哲学是「编译正确性优先」：它只保证 .btn { color: @primary; } 能变成合法 CSS，不负责可读性。所有缩进、空行、对齐，都原样继承自 .less 源码中的空白字符（包括 tab、space、CRLF/LF 差异）。这意味着：
- 你在 VS Code 里用 2 空格缩进嵌套，编译后就是 2 空格；用 4 个 tab？那 CSS 里也全是 tab
- Windows 下保存的
\r\n换行，在 Linux 编译时仍保留为\r\n，而某些 CSS 工具（如clean-css）会把它当非法字符处理 -
@import合并多个文件时，各文件末尾的空行、开头的注释前空行，都会被拼接进最终 CSS
用 --compress 会统一缩进吗？
不会。--compress 的作用是移除所有空白符（包括换行、缩进、多余空格），把整个 CSS 压成单行。它不重排、不标准化、不美化——只是删。例如：
.btn {
display: flex;
justify-content: center;
}
经 lessc input.less --compress 后变成：
立即学习“前端免费学习笔记（深入）”；
.btn{display:flex;justify-content:center;}
这不是“缩进统一”，是“缩进归零”。如果你需要带缩进的规范输出（比如给设计师看、做 code review），--compress 反而会让问题更难排查。
真正可控的缩进方案：用 prettier + postcss
想让编译后 CSS 有稳定、可配置的缩进（比如 2 空格、属性每行一个、大括号换行），必须在 Less 编译之后加一层格式化。推荐链路：
- 先用
lessc input.less > output.css或 Webpack 输出原始 CSS - 再用
prettier --parser css --tab-width 2 output.css格式化（需安装prettier） - 或接入
postcss+postcss-preset-env+postcss-sorting，在构建中自动处理
注意：prettier 对 CSS 的缩进控制比 clean-css 可靠得多，且能识别 @media、@supports 嵌套层级；但别把它和 --compress 混用——前者加缩进，后者删缩进，顺序反了就白跑。
容易被忽略的根源：源文件缩进不一致
很多团队发现“编译后缩进忽宽忽窄”，其实问题不在 Less，而在多人协作时 .less 文件混用了 tab / space、CRLF / LF、甚至编辑器自动插入的不可见字符（如零宽空格 \u200B）。VS Code 开启「Render Whitespace」就能看到这些干扰项。最稳妥的做法是：
- 全团队统一设置：VS Code 的
editor.insertSpaces: true、editor.tabSize: 2、files.eol: "\n" - 提交前用
prettier --write "**/*.less"统一源码格式 - CI 中加检查：若
git diff --check报出 trailing whitespace 或 mixed line endings，直接拒绝合并
Less 本身不生成缩进，它只是忠实反射你写的空白。缩进混乱从来不是编译问题，而是协作规范没落地。
