乱码本质是浏览器用错编码解析css字节流，核心只需两步：确保css文件为utf-8 without bom，并通过http响应头或首行@charset "utf-8"明确声明编码；@charset必须严格位于第一行且无bom、空格或注释，否则失效退至系统locale（如gbk），导致中文双字节被错误拆解而乱码或错位。
直接结论：乱码不是“CSS没加载”，而是浏览器用错编码读取了文件字节流。核心动作只有两个——确保 CSS 文件是 UTF-8 without BOM，且 HTTP 响应头或 @charset 明确告诉浏览器“请用 UTF-8 解析我”。
为什么 @charset "UTF-8" 必须放在第一行且不能有空格
@charset 是 CSS 规范里唯一能覆盖浏览器默认编码的声明，但它极其脆弱：前面哪怕有一个空格、一个换行、一行 /* 注释 */ 或 BOM 字节，整个声明就失效。浏览器立刻退回到系统 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）或完全无此三字节（UTF-8 without BOM）。带 BOM 时@charset无效；无 BOM 时它才起作用 - Webpack/Vite 构建时，
css-loader默认按 UTF-8 读取，但若你手动拼接 CSS 或用了旧版插件，需显式配置encoding: 'utf8'
CSS 文件里写中文 content 为什么还是乱码
即使 @charset 正确、HTTP 头正确，content: "年" 在部分浏览器或打包环境下仍可能显示为方块。这不是编码问题，而是 CSS 规范对裸中文的支持不稳定。
- W3C 只明确定义
\5e74这种 Unicode 转义语法（去掉u前缀，每个码点单独写） -
content: '\u5e74'是 JS 写法，在 CSS 里会被当普通字符串解析，不转义 - 安全做法：用
console.log(escape('年'))得到%u5E74，再手动改成\5e74；或用在线工具转完删掉u - 字体名、注释里的中文同理——注释乱码可能吃掉后续 CSS 结束符，导致整段样式失效
本地 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"> - CDN 或 Nginx 部署时，确认
add_header Content-Type "text/css; charset=utf-8";，且不要被其他配置覆盖
真正容易被忽略的点是：路径里的中文（比如 @import "按钮.css"）和 @charset 完全无关。那部分乱码由服务器 URL 解码逻辑和响应头共同决定，不是改 CSS 文件编码就能解决的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
