必须是中第一个子元素，否则浏览器仅扫描前1024字节且遇bom、注释、空格或即中断查找，fallback至iso-8859-1等默认编码导致乱码，后续声明无效。
meta charset 必须是 中第一个子元素，否则浏览器会按 ISO-8859-1 解析开头字节，后续再声明 UTF-8 也救不回来。
为什么 meta charset="UTF-8" 放错位置就失效
浏览器解析 HTML 时，只扫描前 1024 字节来查找 meta charset；如果前面有 BOM、注释、空格、<title></title> 或 JS 注入，就会跳过或误判。哪怕你写了十遍 meta，只要第一行不是它，就大概率 fallback 到乱码编码（如 Windows-1252）。
-
xxd -l 3 index.html查看文件头：若输出ef bb bf，说明存在 UTF-8 BOM，必须删掉 - VS Code 保存时选 “UTF-8” 而非 “UTF-8 with BOM”
- 不要在
开始前加任何空白、注释或<script></script> - 正确顺序：
<meta charset="UTF-8"> <title>...</title>，不能是<title>...<meta charset="UTF-8"> </title>
HTTP 响应头和 meta 冲突时谁赢
HTTP 响应头中的 Content-Type: text/html; charset=GBK 优先级高于 meta charset —— 浏览器直接按 GBK 解码字节流，后面写的 UTF-8 就被无视了。本地双击打开 file:// 时无响应头，才只看 meta。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- Nginx 配置里写
charset utf-8;（注意小写，不是UTF-8） - Apache 的
.htaccess加AddDefaultCharset UTF-8 - Express 中用
res.set('Content-Type', 'text/html; charset=utf-8').sendFile(...) - Chrome DevTools → Network → HTML 请求 → Response Headers → 确认
content-type含charset=utf-8
编辑器保存编码和文件实际字节不一致怎么办
你在 VS Code 里点了 “UTF-8”，但文件实际存的是 GBK 字节，meta charset="UTF-8" 就是在拿 UTF-8 规则硬解 GBK 字节，结果就是满屏 。
- Linux/macOS 下用
file -i your.html看真实编码；若显示charset=iso-8859-1或gbk，说明保存错了 - Notepad++：编码 → 转为 UTF-8（无 BOM）→ 另存为
- Sublime Text：File → Save with Encoding → UTF-8
- 别信编辑器右下角状态栏——它只显示“当前认为的编码”，不保证文件真实字节
最容易被忽略的是三者必须严格一致：文件真实字节编码、HTTP 响应头 charset、meta charset 值。少一个，浏览器就可能 fallback 到错误编码，而这个 fallback 过程完全静默，连控制台都不报错。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
