@charset必须位于CSS文件最开头，因它用于声明字节流编码，前置空格、BOM或注释会导致浏览器忽略而回退至ISO-8859-1，默认乱码；仅允许一次且紧贴首字符，构建工具可能移除或错位，需手动确保其在最终输出首行。
为什么 @charset 必须放在 CSS 文件最开头？
它不是可选注释，而是告诉浏览器“接下来的字节流该用什么编码解析”。一旦位置错（比如前面有空格、BOM、注释），浏览器直接忽略它，退回到默认编码（通常是 ISO-8859-1），中文、emoji 或特殊符号就全乱码。
- 必须紧贴文件第一个字符，不能有任何前置内容（包括 UTF-8 BOM）
- 只允许出现一次，且只能是
@charset "utf-8";或@charset "UTF-8";（引号内大小写不敏感，但建议小写） - 如果用构建工具（如 Webpack、Vite）处理 CSS，实际输出文件可能被注入前缀，此时手写的
@charset很容易被顶到第二行而失效
VS Code 里保存为 UTF-8 无 BOM，@charset 还需要写吗？
需要。编辑器保存编码只是影响文件字节存储，不改变浏览器加载时的解析逻辑。浏览器不读取文件系统元数据，只靠 @charset 指令或 HTTP Content-Type 头来决定解码方式。
- HTTP 响应头带
Content-Type: text/css; charset=utf-8时，@charset会被忽略（但保留也无害） - 本地双击打开
.css文件（file://协议），没有 HTTP 头，此时@charset是唯一可靠手段 - 某些老旧代理或 CDN 可能剥离或改写响应头，留着
@charset是兜底做法
@charset 和 HTML 的 <meta charset> 有什么关系？
完全无关。HTML 的 <meta charset="utf-8"> 只控制 HTML 文档自身解析，不影响它 link 进来的 CSS 文件。CSS 是独立资源，有自己的编码声明机制。
- CSS 文件里写
@charset "gbk";，哪怕 HTML 声明了 UTF-8，CSS 里的中文照样按 GBK 解——结果就是乱码 - 两者编码不一致时，浏览器不会自动转换，也不会报错，只会静默出错
- 常见误操作：HTML 改成 UTF-8 后忘了同步更新 CSS 文件里的
@charset，或者团队成员本地编辑器默认编码不统一
构建工具场景下怎么避免 @charset 失效？
PostCSS、sass、Less 等工具在编译/合并时可能把 @charset 干掉，或把多个 CSS 文件合并后只保留第一个的声明，导致后续内容解码错乱。
立即学习“前端免费学习笔记（深入）”；
- PostCSS 默认会删除
@charset，需显式启用postcss-import并配置preserve: true - Sass 编译时，如果入口文件没写
@charset，即使被导入的文件写了，最终输出也不含该指令 - 推荐做法：只在最终输出的主 CSS 文件头部写一次
@charset "utf-8";，所有 partial 文件都不要写
最容易被忽略的是：合并多个 CSS 片段时，没人检查最终产物里 @charset 是否还在第一行。一上线，部分字体图标或伪元素里的 Unicode 字符就突然变方块——问题往往卡在这儿，而不是字体本身。
