less编译后中文注释乱码的根本原因是utf-8字节流被错误解码为iso-8859-1或gbk，需确保.less源文件为utf-8无bom、lessc显式以utf-8输出、@charset"utf-8"严格置于css首行且无前置内容，并保证http响应头charset与文件编码一致。
lessc 编译后中文注释变乱码，不是 Less 不支持中文，而是 UTF-8 字节流在某个环节被当成了 ISO-8859-1 或 GBK 解码——只要源文件带 BOM、lessc 重定向输出没锁编码、或 @charset "UTF-8" 没严格放首行，/<em> 中文 </em>/ 就会变成 /<em> 姹傚瓧 </em>/，甚至吃掉 */ 导致整段 CSS 失效。
确认 .less 源文件是 UTF-8 无 BOM
VS Code 右下角显示 “UTF-8” ≠ 真的是 UTF-8 无 BOM；Sublime Text 默认保存可能带 BOM；Notepad++ 选 “UTF-8” 很容易误选成 “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） - 已有 BOM？Linux/macOS 下用：
sed -i '1s/^\xEF\xBB\xBF//' style.less
lessc 输出必须显式指定 UTF-8 编码
lessc 默认把 stdout 当作原始字节流写入，不关心终端 locale。在 Windows PowerShell 或某些 Linux 终端里，lessc input.less > output.css 实际可能生成 GBK 编码的 CSS 文件，哪怕源文件是 UTF-8。
- PowerShell 正确写法：
lessc input.less | Out-File -Encoding UTF8 output.css - Linux/macOS：先确认
locale | grep UTF，再执行重定向 - 最稳妥方式：用 Node.js 脚本调用 API，全程锁定
utf8：const less = require('less');<br>const fs = require('fs').promises;<br><br>(async () => {<br> const content = await fs.readFile('style.less', 'utf8');<br> const { css } = await less.render(content, { paths: ['.'] });<br> await fs.writeFile('style.css', css, 'utf8'); // 关键：第三个参数必须是 'utf8'<br>})();
@charset "UTF-8" 必须严格位于 CSS 首行
@charset 是 CSS 规范中唯一能覆盖浏览器默认编码的声明，但它极其敏感：前面有一个空格、一个换行、一行 /* 注释 */ 或 BOM 字节（EF BB BF），整个声明就失效。失效后浏览器退到系统 locale（Windows 常为 GBK），把 UTF-8 中文双字节错拆成两个非法单字节，结果就是方块或样式失效。
- 打开编译后的
style.css，用xxd style.css | head -1检查开头三字节：不能出现ef bb bf - 手动插入时，必须是文件第一行、无任何前置内容，连零宽空格（
\u200b）都不能有 - 别复制粘贴——某些编辑器会悄悄塞入不可见字符
- Chrome DevTools 的 Sources 面板中打开该 CSS，确认顶部是否高亮显示
@charset "UTF-8"，且无解析错误
HTTP 响应头 charset 优先级高于 @charset
当 CSS 通过 <link> 引入时，浏览器以 HTTP 响应头中的 Content-Type: text/css; charset=utf-8 为最高优先级。@charset 只是备选。如果服务器返回 charset=gbk，哪怕 CSS 文件里写了 @charset "UTF-8"，浏览器仍用 GBK 解码，中文照样乱码。
- Chrome DevTools Network 标签页 → 找对应 CSS 请求 → Headers → Response Headers → 查看
Content-Type是否含charset=utf-8 - Vite / Webpack Dev Server 默认发
charset=utf-8；Nginx 需显式配置charset utf-8; - CDN 或旧 Apache 可能强制覆盖响应头，用
curl -I https://example.com/style.css实测 -
<meta charset="UTF-8">对 CSS 文件完全无效，别指望它“传染”
真正卡住的从来不是 Less 本身，而是从源文件保存、CLI 输出、CSS 声明、HTTP 传输这四层里任意一环脱钩。最容易被忽略的是：改了源文件编码、加了 @charset、也配了 meta，却忘了检查构建工具（如 css-loader）是否默认按 UTF-8 读取，或 Nginx 是否静默覆盖了响应头。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
