Less 编译因源文件换行符不统一（CRLF/LF）导致解析错误、Git diff 异常及 CI 失败；根本解法是 Git 层强制标准化为 LF（.gitattributes + renormalize），并规范编辑器与构建工具链避免引入 CRLF。
Less 编译结果在 Windows 和 macOS/Linux 下出现换行符差异（CRLF vs LF），不是编译器 bug，而是源文件换行符不统一 + 构建工具链未做标准化导致的。直接后果是：Git 提交时大量“看似修改”的 diff、CI 构建失败、甚至触发 Less 解析错误（如 parse error 或 invalid css after ""）。
为什么 CRLF 会让 Less 报错或生成异常 CSS？
Less 解析器对换行符敏感，尤其在以下场景：
- 多行变量赋值（如
@colors: (red, green, blue);）末尾若为 CRLF，可能被截断成不完整 token - 嵌套 mixin 参数列表后紧跟 Windows 换行：
.btn(@size: 12px, @color: #000) { ... }后空行是 CRLF → 解析器误判为参数未闭合 - 块注释
/* ... */跨行时，CRLF 中的\r可能被当作非法字符，触发unrecognised input
强制 Git 统一换行符（最有效且必须第一步）
仅靠编辑器设置不够，Git 层必须拦截并转换。在项目根目录加 .gitattributes 文件：
* text=auto eol=lf
这会让 Git 在 commit 时自动把所有文本文件转为 LF，在 checkout 时按系统还原（但不影响 Less 解析逻辑）。关键点：
立即学习“前端免费学习笔记（深入）”；
- 必须提交该文件，否则 CI 环境不会生效
- 执行
git add --renormalize .强制重写工作区换行符 - VS Code 设置里关掉 “Files: Auto Guess Encoding”，避免 UTF-8 with BOM 干扰
编辑器和构建环节双重校验
Git 控制了存储层，还需确保编辑和构建时不引入新 CRLF：
- VS Code 设置
"files.eol": "\n"，并开启 “Ensure Newline at End of File” - 禁止用 Word、Notepad 等富文本编辑器改 Less 文件——它们默认插入 CRLF + 零宽空格
- Webpack/Vite 构建中，
less-loader不处理换行符，所以源头必须干净；若用lesscCLI，加--no-color参数可减少 ANSI 控制符干扰 - CI 脚本里加检查：运行
grep -rl $'\r' src/**/*.less，非空则失败
别指望压缩工具“修好”换行符
--compress 会删空行，但不转换换行符类型；clean-css 默认输出 LF，但若输入是 CRLF，它可能保留部分原始格式。真正的问题不在输出端，而在 .less 源文件本身是否含 \r。一旦发现编译报错位置飘忽（比如总在注释后一行），先查 xx.less 是否被 Windows 记事本保存过——这种问题无法靠配置绕过，只能从源头清理。
