根本原因是CSS文件编码未正确声明，浏览器按HTTP头或@charset规则解析，若两者皆无则回退系统默认编码（如GBK）导致乱码；@charset "utf-8"必须位于CSS文件首字节、仅出现一次、且文件为UTF-8无BOM。
HTML引入CSS时乱码，根本原因不是HTML没设
很多人以为只要HTML里写了<meta charset="utf-8">，CSS里的中文注释、content属性值（比如content: "编辑";）就一定不会乱码——这是错的。浏览器解析CSS文件是独立于HTML的：它先按HTTP响应头的Content-Type字段判断编码，若无则查文件开头是否有@charset规则；如果两者都缺失，就会退回到系统默认编码（Windows上常是GBK/GB2312），导致CSS中非ASCII字符被错误解码。
CSS文件顶部@charset "utf-8";必须满足三个硬性条件
这条语句不是“写了就有用”，它生效有严格前提：
- 必须是CSS文件的**第一个字节**，前面不能有任何空白、BOM、注释或换行
- 只能出现一次，重复定义（如两个
@charset）时仅第一个生效 - 不能写在
<style>标签内、也不能写在HTML的style属性里，只对独立CSS文件有效
常见翻车现场：/* 注释 */ @charset "utf-8"; → 无效；\n@charset "utf-8";（首行空行）→ 无效；用记事本保存为UTF-8 with BOM → BOM（EF BB BF）会卡在@charset前，直接失效。
为什么不用@charset而依赖HTTP头更危险
现代Web服务器（Nginx/Apache/CDN）通常能配charset utf-8;或AddDefaultCharset UTF-8，但以下场景会让HTTP头失效：
立即学习“前端免费学习笔记（深入）”；
- 本地双击打开HTML（
file://协议），无HTTP头，全靠@charset或BOM兜底 - 开发时用
python -m http.server或Vite预览，某些版本默认不发charset - 内联CSS或
<link rel="stylesheet">指向的路径被代理重写，HTTP头被剥离
这时候如果CSS文件没写@charset "utf-8";，且又没带BOM，Windows用户十有八九看到content: "༭";这种问号块。
实际操作建议：统一用UTF-8 + 显式@charset + 零BOM
别赌服务器配置或编辑器默认行为，直接控制源头：
- 所有CSS文件用编辑器（VS Code/Sublime）保存为
UTF-8（**不含BOM**） - 第一行严格写成
@charset "utf-8";，后面紧跟换行，不要空格 - HTML中
<meta charset="utf-8">仍要保留，但它只管HTML自身，不管CSS - 验证方式：用
xxd style.css | head -n 1看前几个字节，确认是40 63 68 61 72 73 65 74（即@charsetASCII码），而非ef bb bf
最易忽略的一点：团队协作时，有人用Windows记事本改CSS，一保存就加BOM，整个@charset规则当场作废——得盯住编辑器的编码显示状态栏。
