必须置于最开头，因浏览器仅扫描前1024字节识别编码；若前面有bom、注释、空格或等，即失效并fallback至gbk等系统默认编码，导致中文乱码。
meta charset 必须出现在 开头，且前面不能有任何字符（包括 BOM、注释、空格），否则浏览器会 fallback 到系统默认编码（如 Windows 的 GBK），直接导致中文显示为乱码。
为什么 meta charset="UTF-8" 要放在
浏览器解析 HTML 时，只扫描前 1024 字节来识别 meta charset。一旦遇到 <title></title>、<script></script> 或非 ASCII 字符（比如中文标题、emoji、CSS content 属性里的汉字），而此时还没读到 meta charset，就会按系统 locale（如 GBK）解码——后续即使写了 charset="UTF-8" 也救不回来。
-
<title>你好</title> <meta charset="UTF-8">→ 失效：浏览器已用 GBK 解了 “你好”，DOM 中 title 已是乱码 -
<meta charset="UTF-8"> <title>你好</title>→ 有效：UTF-8 解码从第一个字节开始 - 开头有 BOM（
EF BB BF）或注释（<!-- 注释 -->）也会让meta失效
文件实际编码和 meta charset 值必须严格一致
如果 HTML 文件本身是 GBK 编码，却写 <meta charset="UTF-8">，浏览器会强行用 UTF-8 解 GBK 字节流，每个中文变成两三个乱码符号（如 “04”）。反之亦然。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 用
file -i index.html（macOS/Linux）或 PowerShell 的Get-Content index.html -Encoding Byte | Select -First 3检查文件头是否为ef bb bf（BOM） - VS Code 默认保存为 UTF-8，但若打开一个 GBK 文件再保存，不手动选 “Save with Encoding → UTF-8”，就会保留 GBK 编码
- Sublime / Notepad++ 保存时务必选 “UTF-8”，不要选 “UTF-8 with BOM”——BOM 会导致 IE 和部分旧工具解析失败
HTTP 响应头中的 Content-Type 优先级高于 meta charset
当服务器返回 Content-Type: text/html; charset=GBK 时，Chrome/Firefox 会无视 HTML 里的 meta charset="UTF-8"，强制用 GBK 解析。只有在 file:// 协议或响应头没指定 charset 时，meta 才起作用。
- Nginx 配置需加
charset utf-8;（注意小写，在http/server/location块中） - Apache 用
AddDefaultCharset UTF-8（注意大写 UTF），避免影响text/plain等类型 - Express 中不要只写
res.set('Content-Type', 'text/html')，必须显式带 charset：res.set('Content-Type', 'text/html; charset=UTF-8') - 用浏览器 DevTools 的 Network 标签页看 HTML 请求的 Response Headers，确认
Content-Type值
验证是否真正生效的三个关键点
别只看页面显示正常——很多乱码在 DOM 构建、JS 执行、CSS 渲染阶段才暴露。
- 在控制台执行
document.characterSet和document.inputEncoding，两者都应返回"UTF-8" - 检查 Network → Response → Preview 里中文是否可读（不是一堆方框或问号）
- 把含中文的 JS 字符串（如
console.log("测试")）和 CSScontent属性单独拎出来测，它们依赖 HTML 的编码上下文
最容易被忽略的是：编辑器保存编码、HTTP 响应头、HTML meta 三者必须完全对齐，缺一不可。任何一个环节错位，都会在某个环节（比如 JS alert 弹窗、CSS 伪元素、AJAX 返回文本）突然爆出乱码，而且很难定位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
