不是乱码，是dart sass将unicode转义序列（如\e6df）主动展开为双字节字符（如“”），而cdn、压缩工具或nginx未正确处理utf-8编码导致显示异常。
不是乱码，是 Dart Sass 主动把 Unicode 转义展开成真实字符，而某些构建环节（如压缩、CDN、旧版 postcss 插件）没正确处理双字节字符。
为什么注释里中文变成方块或问号
Dart Sass 默认将 \e6df 这类 Unicode 转义序列直接渲染为对应汉字或图标字符（如 “编” 或 “”），而不是保留 "\e6df" 字符串。这本身符合 CSS 规范，但问题出在后续环节：
- 某些 CSS 压缩工具（如
cssnano低版本）会错误解析双字节字符，删掉、截断或转成无效字节 - CDN 或 Nginx 未设置
charset=utf-8响应头，浏览器用 GBK 解析 UTF-8 字节流，中文就变方块 - VS Code 保存时误选了
UTF-8 with BOM，导致@charset "UTF-8"失效（BOM 在首行会破坏该声明） - 注释写在
@import或@use上方，被 Dart Sass 当作“非 CSS 内容”跳过编码处理，实际未参与输出
content: "\e6df" 编译后变空或乱码的真正原因
这不是注释问题，而是伪元素 content 值被展开后，遭遇了不兼容的下游工具。Element UI 等库的 icon 依赖 content: "\e6df" 这种写法，Dart Sass 编译后变成 content: ""，但：
-
css-loader+mini-css-extract-plugin在 Webpack 5 下默认启用esModule: true，可能对双字节字符做额外转义 -
sass-loader若配置了outputStyle: 'compressed'（Vue CLI 旧版默认），会进一步触发 Unicode 展开+压缩组合问题 - 打包后 dist 目录下 CSS 文件若用记事本打开显示乱码，大概率是文件本身编码正常，但编辑器用了错误编码读取（非文件问题）
怎么验证和修复
先确认是不是真乱码，再针对性处理：
- 用
xxd dist/css/app.css | head -20查看开头是否含ef bb bf（BOM）；有则重存为UTF-8 without BOM - 打开 Chrome DevTools → Network → 找 CSS 请求 → Response Headers → 确认
Content-Type: text/css; charset=utf-8 - 在
vue.config.js或webpack.config.js中强制指定sassOptions: { outputStyle: 'expanded' }，避免 compressed 模式加剧 Unicode 展开副作用 - 若仍不行，临时加
@charset "UTF-8";到 SCSS 文件最顶部（第一行，无空格/注释/BOM），确保它出现在最终 CSS 首行
最容易被忽略的是：你改了 SCSS，但构建产物里的 CSS 文件可能缓存了旧版本，或者被 CDN 强制缓存了带错误响应头的副本——清缓存、查响应头、看原始字节，比反复改配置更有效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
