Less编译后CSS中文乱码的根本原因是编译链路中UTF-8字节流被错误解码为ISO-8859-1或GBK，需确保源文件UTF-8无BOM、lessc显式以utf8编码输出、@charset"UTF-8"严格置于CSS首行且无前置内容，并在Webpack中配置css-loader encoding及HTTP响应头charset匹配。
Less 编译后 CSS 中中文注释变乱码，根本不是 Less 本身不支持中文，而是编译链路中某处把 UTF-8 字节流当成了 ISO-8859-1 或 GBK 解码——只要源文件是 UTF-8 无 BOM、lessc 输出时没强制编码、浏览器或编辑器又没对上，/* 中文 */ 就会变成 /* 涓夋眽 */，甚至吃掉后续的 */ 导致整段 CSS 失效。
确认 .less 源文件确实是 UTF-8 无 BOM
很多乱码问题其实在第一步就埋下了。VS Code 右下角显示 “UTF-8” 不代表就是无 BOM；Sublime Text 保存时选 “UTF-8” 默认可能带 BOM；Notepad++ 更容易误选 “UTF-8-BOM”。BOM（\uFEFF）插在文件开头，会让 @charset "UTF-8"; 失效，也会干扰 less.render() 的输入解析。
- 用命令行验证：
file -i style.less输出必须含charset=utf-8，且不含with BOM - VS Code：右下角点击编码 → “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM） - Sublime Text：菜单
File → Save with Encoding → UTF-8 - 如果已有 BOM，可用
sed -i '1s/^\xEF\xBB\xBF//' style.less（Linux/macOS）清除
lessc 命令行编译必须显式控制输出编码
lessc 默认把 stdout 当作字节流直接写入文件，完全不管你的终端 locale 或编辑器偏好。在 macOS 或某些 Linux 环境下，lessc input.less > output.css 实际可能生成 GBK 或 ISO-8859-1 编码的 CSS 文件，哪怕源文件是 UTF-8。
- Linux/macOS：确保终端 locale 是 UTF-8（
locale | grep UTF），再执行重定向 - PowerShell：改用
lessc input.less | Out-File -Encoding UTF8 output.css - 最稳妥方式：别用 shell 重定向，改用 Node.js 脚本调用 API，显式传
'utf8'：
const less = require('less');
const fs = require('fs').promises;
<p>(async () => {
const content = await fs.readFile('style.less', 'utf8');
const { css } = await less.render(content, { paths: ['.'] });
await fs.writeFile('style.css', css, 'utf8'); // 关键：第三个参数必须是 'utf8'
})();这样绕过了 shell 编码不确定性，从读、编、写全程锁定 UTF-8。
立即学习“前端免费学习笔记（深入）”；
@charset "UTF-8" 必须是 CSS 文件第一行且无任何前置内容
很多人加了 @charset "UTF-8"; 还是乱码，是因为它被放在注释后面、空行之后，或者前面有 BOM。CSS 规范规定：该声明必须是文件**绝对第一行**，**第一个字符就是 @**，前面不能有任何空白、BOM、注释。
- 正确写法（打开
style.css用十六进制编辑器确认开头是40 63 68 61 72 73 65 74）：
@charset "UTF-8";
body { color: #333; }- 错误写法（以下任一都会让声明失效）：
/* 全局样式 */
@charset "UTF-8"; // ← 注释在前，无效
@charset 'utf-8'; // ← 单引号非标准，部分 loader 拒绝解析
\uFEFF@charset "UTF-8"; // ← BOM 在前，浏览器忽略该行
@charset "UTF-8";\n\nbody { ... } // ← 空行在后不影响，但前面绝不能有东西加完后务必用 curl -s your-site.com/style.css | head -n1 或直接用 VS Code 以“纯文本”模式打开检查首行。
Webpack + less-loader 场景下额外注意 css-loader 和 HTTP 响应头
即使你本地编译出的 CSS 没问题，Webpack 构建后仍乱码，大概率卡在 css-loader 或服务层。旧版 css-loader（@charset 解析不完整；Nginx 若未配置 charset，会默认返回 text/css; charset=gbk，浏览器就强行按 GBK 解 UTF-8 字节。
-
less-loader配置里加implementation: require('less')（否则可能降级用内置 parser） -
css-loader版本 ≥ 6.0，并确保没配esModule: false（会破坏 @charset 识别） - Nginx 配置加：
add_header Content-Type text/css; charset=utf-8;或更稳妥：charset utf-8; - Vite / Webpack Dev Server 默认发
charset=utf-8，但上线后 CDN 或 Nginx 往往覆盖它，必须单独校验 Response Headers
真正容易被忽略的是：你改了 .less 文件编码、加了 @charset、也写了脚本强制 'utf8' 写入，却忘了检查 Nginx 日志里有没有 charset gbk 的警告——这种配置级问题不会报错，只会静默把 UTF-8 字节喂给 GBK 解码器。
