Less编译后CSS乱码根本原因是文件字节流被错误解码，而非编译器出错；需统一源文件UTF-8无BOM保存、编译命令显式指定UTF-8输出、CSS头部正确添加@charset"UTF-8"（首行无空格/BOM），并确保HTTP响应头charset与文件真实编码一致。
Less 编译后 CSS 文件出现乱码，根本不是编译器“把中文搞错了”，而是文件字节流在某个环节被错误解码——编译器输出的字节本身没问题，但读取或渲染它的程序（浏览器、编辑器、服务器）用了不匹配的编码去解释。
Less 编译器本身不控制输出文件编码
Less CLI（lessc）默认将输出内容以系统 stdout 编码写入文件，不主动声明或转换编码。这意味着：
- 在 Windows 中，若终端
chcp是 936（GBK），lessc input.less > output.css生成的 CSS 文件实际是 GBK 编码字节，哪怕源 Less 是 UTF-8 - VS Code 或 Sublime 默认用 UTF-8 读取该文件，就会把两个 GBK 字节错解为一个非法 UTF-8 序列，显示为 或方块
-
@charset "UTF-8";写在编译后 CSS 头部也无效——它只是告诉 CSS 解析器“接下来的内容按 UTF-8 解”，但文件本身根本不是 UTF-8 字节
浏览器加载时二次解码失败
即使你手动把编译后的 output.css 用编辑器另存为 UTF-8 无 BOM，仍可能乱码，原因在传输链路：
- 本地双击打开
file://协议下的 CSS，浏览器依赖文件 BOM 或编辑器保存格式，无 BOM 且无@charset时行为不一致 - 走 HTTP 服务时，关键看响应头：
Content-Type: text/css; charset=utf-8必须存在且与文件真实编码匹配；若服务器返回charset=gbk，哪怕文件是 UTF-8 也会被强转 - HTML 中
<meta charset="UTF-8">只影响 HTML 本身，对<link rel="stylesheet">加载的 CSS 无约束力
真正可控的修复点只有三个
别试图让 Less “自动输出 UTF-8”，它没这个开关。你必须在上下游卡住三处：
- 源 Less 文件：用 VS Code 等编辑器确认保存为 UTF-8 无 BOM（右下角点击编码 → Save with Encoding → UTF-8）
- 编译命令：显式重定向并指定编码，例如在 PowerShell 中：
lessc input.less | Out-File -Encoding UTF8 output.css；Linux/macOS 下确保locale是en_US.UTF-8或zh_CN.UTF-8，再执行lessc input.less > output.css - 最终 CSS 文件头部：手动插入
@charset "UTF-8";作为第一行（不能有空格、BOM、注释），且仅当文件确实是 UTF-8 无 BOM 时才加——加错反而触发解析异常
最易被忽略的是：很多人改了 Less 源文件编码、加了 @charset、也设置了 HTML meta，却忘了检查 Webpack 的 css-loader 是否配置了 encoding: 'utf8'，或者 Nginx/Apache 是否覆盖了 charset 响应头。乱码从来不是单点问题，而是一条链上任意一环脱钩的结果。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
