CSS乱码主因是编码不匹配，须确保文件为UTF-8无BOM且通过@charset或HTTP头声明UTF-8；@charset必须首行无空格/BOM，否则退至GBK导致错乱；中文content需用\5e74等Unicode转义；file://下@charset无效，应启用本地服务。
乱码不是 CSS 没加载，而是浏览器用错了编码去读取字节流。核心就两件事：CSS 文件必须是 UTF-8 without BOM，且必须通过 @charset "UTF-8" 或 HTTP 响应头明确告诉浏览器“请用 UTF-8 解析我”。
为什么 @charset 必须严格放在第一行
@charset 是 CSS 规范里唯一能覆盖浏览器默认编码的声明，但它极其敏感：
- 前面哪怕有一个空格、一个换行、一行
/* 注释 */或 BOM 字节（EF BB BF），整个声明就失效 - 失效后浏览器退回到系统 locale（Windows 下常为
GBK），把 UTF-8 的中文双字节当两个单字节拆开处理，结果就是错位、方块或整段样式失效 - VS Code 右下角点击编码 → “Save with Encoding” → 必须选
UTF-8（不是UTF-8 with BOM） - 用
xxd style.css | head -1检查开头三字节：不能出现ef bb bf；有 BOM 时@charset白写
CSS 文件里写中文 content 还是乱码怎么办
这不是编码问题，而是 CSS 对裸中文支持不稳定。W3C 明确定义的只有 Unicode 转义语法（去掉 u 前缀，每个码点单独写）：
-
content: '\u5e74'是 JS 写法，在 CSS 里会被当普通字符串，不转义 - 正确写法是
content: '\5e74'（注意没有u，斜杠后直接四位十六进制） - 可用
escape('年')得到%u5E74，再手动改成\5e74；或用在线工具转完删掉u - 字体名、注释里的中文同理——注释乱码可能吃掉后续
*/，导致整段样式被注释掉
本地 file:// 协议下 @charset 完全无效
没有 HTTP 协议，就没有 Content-Type 响应头，@charset 在 file:// 下被大多数浏览器忽略：
立即学习“前端免费学习笔记（深入）”；
- 此时全靠浏览器“猜”：看 HTML 是否有
<meta charset="UTF-8">、系统 locale、甚至文件 BOM —— 都不可靠 - 开发阶段务必用本地服务：
vite dev、python -m http.server、live-server，别双击打开 HTML - 如果必须用
file://，CSS 文件只能存为UTF-8 with BOM（虽违反规范，但 IE/Edge 会认），且 HTML 必须有<meta charset="UTF-8">
最容易被忽略的点是：路径里的中文（比如 url("图标.css") 或 @import "按钮.css"）和 @charset 无关。它只影响 CSS 文件自身文本解析，不干预 URL 编码逻辑。这类问题得靠服务器配置 charset utf-8 或干脆避开中文路径。
