必须紧贴开头、前无任何字符（含空格、换行、注释、bom），因浏览器仅扫描前1024字节识别该标签，否则fallback至gbk或iso-8859-1导致乱码、emoji异常、js语法错误。
meta charset必须紧贴开头写
浏览器只扫描 HTML 文件前 1024 字节找 meta charset，一旦被干扰就直接 fallback 到 GBK 或 ISO-8859-1。常见干扰包括：
-
后有空格、换行、<!-- 注释 -->或不可见 Unicode 字符（如 ZERO WIDTH SPACE） -
<title></title>或<script></script>出现在meta charset前面 - BOM（
EF BB BF）占了文件头 3 字节，导致后续meta被“偏移错过”
修复方式：打开源码，把 <meta charset="UTF-8"> 移到 标签正后方，前面不能有任何字符（包括空格和换行），后面可跟 <title></title> 等其他标签。
别用替代charset
HTML5 中 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 已废弃，且部分浏览器会忽略它，甚至干扰 meta charset 解析。
必须删掉所有这类旧式声明，只保留一个 <meta charset="UTF-8">，且确保它在 内唯一。
注意：charset="utf8" 和 charset="UTF8" 都不是标准值，浏览器可能不认；必须是 charset="UTF-8"（连字符不能少，大小写不敏感但推荐大写 U、T、F）。
文件真实编码 ≠ 编辑器右下角显示的编码
VS Code 右下角写着 “UTF-8”，不代表文件真是 UTF-8（无 BOM）。很多编辑器默认保存为 “UTF-8 with BOM”，而 BOM 会破坏 meta charset 生效逻辑。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
验证真实编码的方法：
- Linux/macOS：
file -i yourfile.html→ 输出含charset=utf-8才可信 - Linux/macOS：
head -c 4 yourfile.html | xxd→ 若含ef bb bf，说明带 BOM - Windows PowerShell：
Get-Content yourfile.html -Encoding Byte | Select -First 3→ 若输出239 187 191，就是 BOM
确认是 GBK 编码时，先用 “Reopen with Encoding” 以 GBK 重新打开，再执行 “Save with Encoding → UTF-8”（不是 “UTF-8 with BOM”）。
本地双击打开（file://）时乱码，基本就是BOM或编码错
这种场景下 HTTP 响应头完全失效，浏览器 100% 依赖文件真实编码 + meta charset。而 Windows 上多数编辑器（Notepad++、旧版 VS Code）默认加 BOM，或把 GBK 文件误标为 UTF-8，一打开就乱。
关键动作只有三步，缺一不可：
- 用上述命令验证真实编码，不是靠编辑器右下角
- 如果是 GBK，先以 GBK 重新打开，再另存为 UTF-8（无 BOM）
- 确保
<meta charset="UTF-8">是内第一个非空白、非注释子元素
模板结构必须长这样：
<meta charset="UTF-8"><title>页面标题</title>中文内容
任何多余字符、缩进、注释出现在 <meta charset> 前，都会让整个机制失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
