@charset 声明必须位于 CSS 文件绝对开头且无 BOM，浏览器按 @charset、BOM、HTTP 头优先级解码；HTML 中的 charset 属性和 meta 标签对 CSS 编码无效。
@charset 只在 CSS 文件里有效，写在 HTML 的 <link> 标签里完全没用——浏览器根本不认 charset 属性，也不支持它。
为什么 link 标签加 charset 属性是徒劳的
HTML5 规范早已移除 <link rel="stylesheet"> 的 charset 属性。现代浏览器（Chrome/Firefox/Safari/Edge）全部忽略它，既不报错，也不起效。你写 <link rel="stylesheet" href="a.css" charset="UTF-8">，和不写一样。
- 旧式写法如
<link rel="stylesheet" charset="utf-8">在 IE 中曾有极有限支持，但早已废弃且不可靠 - 即使服务器返回
Content-Type: text/css; charset=gbk，浏览器也不会按这个charset去解码——它优先看 CSS 文件自身的@charset或 BOM，其次才是 HTTP 头 - 试图用
charset属性“覆盖”编码，本质是方向错误：问题不在 HTML 怎么引，而在 CSS 文件本身怎么存、怎么声明
@charset 必须出现在 CSS 文件最开头，且不能有 BOM 干扰
浏览器只在 CSS 文件字节流的**绝对开头**（第 1 字节）识别 @charset。任何前置内容都会让它失效：
- ✅ 正确：
@charset "UTF-8";—— 文件开头第一字符就是@ - ❌ 失效：BOM（
EF BB BF）在前 →@charset实际位于第 4 字节，被跳过 - ❌ 失效：前面有空格、换行、注释（哪怕
/* */）→ 不再是“第一行” - ❌ 失效：写了两遍
@charset→ 只有第一个有效，第二个被忽略（但没必要冒险）
验证方式：xxd -l 16 style.css 看前 16 字节，应为 40 63 68 61 72 73 65 74 20 22 55 54 46 2d 38 22（即 @charset "UTF-8" ASCII 编码），而非以 ef bb bf 开头。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
真正起作用的三层编码控制，优先级从高到低
浏览器决定如何解码一个 CSS 文件，顺序很明确：
- ① CSS 文件开头的
@charset "UTF-8";（硬编码，最高优先级） - ② CSS 文件是否含 UTF-8 BOM（
EF BB BF，次高；但 BOM 和@charset同时存在时，@charset仍胜出） - ③ HTTP 响应头
Content-Type: text/css; charset=utf-8（开发服务器常漏配，Nginx/Apache 需显式设charset utf-8;）
HTML 中的 <meta charset="UTF-8"> 对 CSS 解码**完全无影响**——它只管 HTML 自身。别指望靠它“带”CSS 一起编码正确。
Windows 下编辑 CSS 文件最容易踩的坑
VS Code / Sublime / Notepad++ 默认保存为 “UTF-8 without BOM”，这会导致：
- 若没手动加
@charset "UTF-8";，Windows 系统（尤其老版 IE/Edge）大概率 fallback 到 GBK，content: "你好";直接变方块 - AI 辅助生成的 CSS 常漏掉
@charset，或写成@charset"UTF-8";（缺空格）→ 语法错误，整条规则失效 - 用 Python
http.server或 Vite 默认开发服务时，HTTP 响应头不含charset，此时全靠 CSS 文件自身声明
实操底线：用 VS Code 保存 CSS 时，右下角点击编码 → “Save with Encoding” → 选 “UTF-8”（不是 “UTF-8 with BOM”），然后**手敲一行 @charset "UTF-8";，确保它在文件最顶上、前面绝无空格或空行**。
