@charset 必须位于 CSS 文件最开头且无任何前置字符（包括 BOM、空格、注释），否则失效，导致中文注释乱码并可能破坏后续 CSS 解析；HTML 的 meta charset 不影响外部 CSS 编码。
@charset 必须写在 CSS 文件第一行
因为 @charset 是 CSS 规范里唯一被允许声明文件编码的语句，但它只在文件**最开头、无任何字符（包括空格、BOM、注释）之前**才有效。一旦前面有 BOM 或空行，浏览器就直接忽略它，退回到默认编码（通常是系统 locale，比如 Windows 上是 GBK），导致后续中文注释被错误解析。
- VS Code 保存时选 “UTF-8 with BOM” → BOM 占前 3 字节 →
@charset "UTF-8";实际成了第 4 行 → 失效 - 有人把
@charset写在/* 注释 */后面 → 浏览器不认 → 按 ISO-8859-1 解析中文 → 出现/*涓夋眽瀛?*/这类乱码 - Webpack 的
css-loader默认用 UTF-8 读取，但若你手动用了fs.readFileSync(path, 'binary')→ 二进制读取后未转码 → 同样乱码
HTML meta 和 HTTP Content-Type 不影响外部 CSS 编码
很多人误以为只要 HTML 里写了 <meta charset="UTF-8">，引入的外部 CSS 就会自动按 UTF-8 解析——这是错的。外部 CSS 是独立 HTTP 请求，它的编码由三者决定：文件自身的 @charset、HTTP 响应头 Content-Type: text/css; charset=xxx、或浏览器 fallback（无前两者时）。HTML 的 meta 只管 HTML 文档本身。
- 本地用
file://打开 HTML → 没有 HTTP 头 → 完全依赖@charset或编辑器保存编码 - Nginx 默认不加
charset到 CSS 响应头 → 若 CSS 文件没@charset，Chrome 可能按 GBK 解析 → 中文注释炸开 - Vite 开发服务器默认加
Content-Type: text/css; charset=utf-8→ 此时@charset可省，但生产构建后 CDN 可能不带该头 → 仍建议保留
中文注释乱码会直接让后续 CSS 失效
这不是“显示不好看”的问题，而是语法破坏。CSS 注释以 /* 开始、*/ 结束。当编码错乱，比如 /*黑体*/ 变成 /*榛戜綋*/，中间的 */ 可能被拆成两个字节散落在乱码里，导致浏览器找不到合法结束符——从那行开始，后面所有样式规则都被当成注释吞掉。
- 典型现象：页面样式突然大面积丢失，但 DevTools 的 Elements 面板里能看到元素、Styles 面板却空空如也
- 验证方法：直接在浏览器地址栏打开 CSS 文件 URL，看源码是否正常显示中文；若显示方块或问号，说明传输/解析环节已出错
- 临时绕过：把中文注释全删掉或改英文 → 如果样式立刻恢复，基本锁定是注释编码问题
比 @charset 更稳的实践是根本不用中文注释
@charset 看似简单，但在跨工具链（Git、CI、CDN、不同编辑器）时极易断裂。真正鲁棒的做法是：CSS 文件里彻底避免中文字符，包括注释、content 值、字体名。
立即学习“前端免费学习笔记（深入）”；
- 注释用英文：哪怕只是
/* btn hover state */，也比/* 按钮悬停状态 */少一堆风险 - 字体名用别名：
font-family: "Microsoft YaHei", "SimSun", sans-serif;，不写"微软雅黑" - 伪元素 content 用 Unicode：
div::before { content: "\7F51\9875\94FE\63A5"; }（对应“网页链接”） - 构建时加校验：用 ESLint 插件
stylelint配no-invalid-position-at-import-rule和unicode-bom规则，提前拦截 BOM 和错位@charset
实际项目里，@charset 往往只是个“安慰剂”——它起作用的前提太苛刻，而失效时又不报错。真正要盯住的，是整个工作流中每个环节对字节流的处理方式：编辑器保存、Git 提交、构建工具读取、HTTP 服务响应、浏览器解析。任何一个环节悄悄换了编码，中文就塌方。
