Less 解析器不进行字符编码转换，直接按字节流切分 token，遇 UTF-8 中文即报 ParseError；需确保文件为 UTF-8 无 BOM、路径与注释避用中文、关键中文转 Unicode 转义，并在构建链路中显式指定 UTF-8 编码。
Less 解析器根本不解码，遇到中文就停
Less 的词法分析器在读取源文件时，不做任何字符编码转换——它直接按字节流切 token。一旦碰到非 ASCII 字符（比如中文注释 /* 按钮样式 */），就会卡在第一个汉字的 UTF-8 多字节序列上，报 ParseError: Unrecognised input。这不是“显示乱码”，而是根本没解析下去，后续样式全丢。
- VS Code 里复制网页代码进来，常带 U+200B 零宽空格，
/*按钮*/看似正常，实际让 Less 直接崩溃 - @import 路径含中文（如
@import "../组件/基础.less";）也会触发同一错误，Less 原生不支持中文路径 - 旧版 Less（≤3.13.x）会把
;和紧挨着的/* 注释 */黏成一个非法 token，必须让注释独占一行且前后空行
VS Code 显示 “UTF-8” 不代表安全
右下角写着 “UTF-8”，但可能是 UTF-8 with BOM。BOM（\uFEFF）三个字节出现在文件开头，会让 @charset "UTF-8"; 失效，Less 读到的第一个字符就是 BOM，直接报错或跳过声明，后面所有中文都按系统 locale（Windows 默认 GBK）误读。
- 验证方式：
file -i style.less输出必须含charset=utf-8且不含with BOM - 清除 BOM：
sed -i '1s/^\xEF\xBB\xBF//' style.less（Linux/macOS）；Windows 用 Notepad++ → “编码” → “转为 UTF-8 无 BOM 格式” - VS Code 保存时务必选 “UTF-8”（不是 “UTF-8 with BOM”），右下角点击后弹出菜单里有两个选项，别选错
真正该写中文的地方，得绕过 Less 解析
content、字体名、伪元素文本这些最终要渲染的中文，不能靠 Less 编译时保留——因为 Less 只负责生成 CSS 字符串，不控制浏览器怎么读。稳妥做法是提前转成 Unicode 转义：
-
content: "\5C55\5F00";（对应 “展开”）比content: "展开";安全得多 - 字体名同理：
font-family: "\9ED1\4F53", sans-serif;（黑体），避免font-family: "黑体";在 GBK 环境下被拆成两个乱码字节 - Chrome 控制台执行
escape("年")得"%u5E74"，去掉%u换成\5E74即可直接用
构建链路里最容易漏掉的一环
Webpack + less-loader 默认调 fs.readFileSync(path)，不传 encoding 参数。Node.js 在 Windows 上可能默认用 GBK 读文件，哪怕你 .less 是 UTF-8 无 BOM，读出来就是错的字节——这时 @charset 和转义都救不了。
立即学习“前端免费学习笔记（深入）”；
- 必须显式配置：
less-loader的implementation项设为require('less')，并确保css-loader ≥ v6.0 - 命令行编译也别用
lessc a.less > b.css，重定向受 shell locale 影响；改用 Node.js 脚本，fs.readFileSync(..., 'utf8')显式指定 - 本地开发别双击打开 HTML ——
file://协议下浏览器忽略@charset，全靠 BOM 或系统猜，唯一可靠的是起本地服务（vite dev或python -m http.server）
真正麻烦的不是“怎么写中文”，而是整个工具链里任意一环（编辑器保存、Less 解析、Node.js 读取、HTTP 响应头、浏览器加载）只要有一个没对齐 UTF-8，中文就变成触发崩溃或静默失效的引信。
