less编译css中文乱码根本原因是utf-8字节流在文件读入、编译输出或浏览器加载任一环节被误解为gbk/iso-8859-1；@charset"utf-8"必须为首行首字符且无bom，lessc重定向需确保终端locale为utf-8，http响应头charset=utf-8优先级高于@charset。
Less 编译后 CSS 出现乱码，不是 Less 不支持中文，而是编译链路中某处把 UTF-8 字节流当成了 GBK 或 ISO-8859-1 解码——从文件读入、编译输出到浏览器加载，三处编码不一致，任意一环断裂都会导致 /* 中文 */ 变成 /* 姹犳枃 */，甚至吃掉 */ 让整段 CSS 失效。
为什么 @charset "UTF-8" 加了也没用
@charset 只对最终生成的 CSS 文件生效，且极其脆弱：
- 必须是 CSS 文件第一行、第一个字符——前面不能有 BOM（
\uFEFF）、空格、空行或注释 - VS Code 右下角显示 “UTF-8” ≠ 无 BOM；Sublime/Notepad++ 默认保存可能带 BOM
- 用
xxd style.css | head -1检查开头三字节：出现ef bb bf就说明带 BOM，此时@charset直接失效 - 大小写敏感：
@charset "utf-8"在旧版 Less 中会被忽略，必须写@charset "UTF-8"
lessc 命令行重定向为什么会丢编码
lessc input.less > output.css 是最常见却最危险的操作：
- lessc 把 stdout 当作原始字节流输出，不关心终端 locale 或编码偏好
- PowerShell / macOS Terminal 若 locale 不是 UTF-8，重定向后生成的 CSS 很可能被存为 GBK 或 ISO-8859-1
- Linux/macOS 下建议先执行
locale | grep UTF确认环境，再运行命令 - 更稳妥方式是绕过 shell：用 Node.js 脚本调用 API，显式指定
'utf8'编码读写
为什么 .less 源文件存成 UTF-8 还是报错
错误可能根本没走到 Less 解析阶段——Ruby（Sass）或某些 less-loader 内置环境在读文件时就崩了：
- Ruby 默认
Encoding.default_external = Encoding.find('GBK')，遇到 UTF-8 中文直接抛Invalid GBK character "\xE5" - Koala / CodeKit / Angular CLI 内置的 Ruby 或 less-loader 版本可能自带编码限制，改编辑器保存方式无效
- Windows 下项目路径含中文（如
D:\我的项目\style.less）也会触发 Ruby I/O 异常 - VS Code 里复制粘贴的
@charset行可能悄悄带零宽空格（\u200b），需开启“显示控制字符”排查
浏览器加载时还乱码？检查 HTTP 响应头优先级
@charset 是备选方案，HTTP Content-Type: text/css; charset=utf-8 才是最高优先级：
- Chrome DevTools → Network → 找 CSS 请求 → Response Headers → 看
Content-Type是否含charset=utf-8 - Vite/Webpack Dev Server 默认发对，但 Nginx 需手动加
charset utf-8;，CDN 可能覆盖响应头 -
<meta charset="UTF-8">对 HTML 有效，对引入的 CSS 完全无效 - 本地
file://协议下@charset基本失效，必须起服务（vite dev、python -m http.server）
真正容易被忽略的是：路径里的中文（比如 @import "按钮.css"）和构建工具链中未显式声明编码的 fs 操作——它们不会报错，但会在某个深夜让你对着空白页面反复刷新。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
