乱码几乎全是编码不一致导致的，核心动作就两步——统一用utf-8（无bom），且css文件第一行加@charset "utf-8"；该声明必须是文件第一个字符，前面不能有bom、空格或注释，否则被忽略而回退至iso-8859-1；http响应头content-type中的charset优先级更高，需确保为text/css; charset=utf-8。
直接结论：乱码几乎全是编码不一致导致的，核心动作就两步——统一用 UTF-8（无 BOM），且 CSS 文件第一行加 @charset "UTF-8";。
VS Code / Sublime 等编辑器保存时选错编码
很多编辑器默认保存为系统 locale 编码（比如 Windows 中文版是 GBK），而浏览器按 <meta charset="UTF-8"> 解析 HTML，却用 GBK 去读 UTF-8 写的 CSS，半个汉字拼错，注释或引号就“断掉”，后面整段 CSS 失效。
- 在 VS Code 中：右下角点击编码名称（如 “GBK” 或 “UTF-8 with BOM”）→ 选
Save with Encoding→ 选UTF-8（**不是 UTF-8 with BOM**） - 在 Sublime Text 中：菜单
File → Save with Encoding → UTF-8 - Notepad++：菜单
格式 → 以 UTF-8 格式编码（别选“UTF-8-BOM”）
CSS 文件开头没写 @charset 或位置不对
@charset 是 CSS 规范中唯一能显式声明文件编码的方式，但它必须是文件**第一行、第一个字符**，前面不能有空格、BOM、注释，否则被忽略，浏览器退回到“猜编码”逻辑，极易出错。
- 正确写法（
style.css开头）：@charset "UTF-8"; body { color: #333; } - 错误写法示例：
/* 注释 */ @charset "UTF-8";（注释在前，失效）、\uFEFF@charset "UTF-8";（BOM 在前，部分浏览器忽略）、@charset 'utf-8';（单引号非标准，某些 loader 不认） - 如果用 Webpack +
css-loader，它默认按 UTF-8 读取，但若项目里混了旧配置，仍建议保留@charset作为兜底
HTML 的 <meta> 和 HTTP 响应头冲突
浏览器优先按 HTTP 响应头的 Content-Type: text/css; charset=gbk 解析 CSS，哪怕你写了 @charset "UTF-8" 也无效。常见于本地 file:// 打开、Nginx 配置强制 charset、CDN 缓存了旧响应头。
- 检查方式：Chrome DevTools →
Network标签 → 找到 CSS 请求 → 看Headers → Response Headers → Content-Type，确认含charset=utf-8 - 本地开发用
file://时，HTTP 头不存在，全靠@charset和<meta>，此时<meta charset="UTF-8">对 CSS 无效（只影响 HTML），必须依赖 CSS 文件自身的@charset - Nginx 配置中避免写
charset gbk;；Vite / Webpack Dev Server 默认发charset=utf-8，一般不用调
真正容易被忽略的是：即使所有地方都标了 UTF-8，只要 CSS 文件实际保存时带了 BOM（尤其是 VS Code 误点“UTF-8 with BOM”），@charset 就会失效，浏览器继续瞎猜。所以每次改完编码，务必用十六进制编辑器或命令行 xxd style.css | head 确认开头没有 ef bb bf 字节。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
