必须位于HTML文件前1024字节内且前面无任何字符（含BOM、空格、换行、注释、等），否则浏览器无法识别而回退至系统默认编码（如Windows的GBK），导致中文乱码。
直接说结论：meta charset="UTF-8" 生效的前提是——它必须被浏览器“看到”，而浏览器只在 HTML 文件前 1024 字节内找这个标签；一旦前面有 BOM、注释、空格、换行或
为什么 meta charset="UTF-8" 没起作用
浏览器解析 HTML 时，并不会读完整个文件再决定用什么编码。它只扫描开头约 1024 字节，寻找第一个有效的 meta charset 声明。如果没找到，就按响应头或系统默认来猜。
-
写在里，但前面插了或两个空行？→ 失效 - 文件开头有 BOM（
ef bb bf）？→ 浏览器可能把它当无效字节跳过，导致后续标签偏移出扫描范围 -
<script></script>出现在meta前？→ 不符合 HTML5 规范，部分浏览器直接忽略 - 用了模板引擎（如 Thymeleaf、EJS），动态注入了额外内容到
开头？→ 实际渲染出来的 HTML 已经不满足“第一 meta”的条件
怎么验证文件实际编码是不是 UTF-8（不含 BOM）
编辑器显示 “UTF-8” ≠ 文件真是 UTF-8 编码。VS Code 默认保存为 UTF-8 with BOM，而 BOM 在 Web 场景中多数时候是隐患。
- Linux/macOS：
file -i index.html看声明，再用xxd -l 4 index.html看头 4 字节：出现ef bb bf就是带 BOM 的 UTF-8 - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，输出239 187 191就是 BOM - Notepad++：右下角状态栏直接显示编码，选“转为 UTF-8”（不是“UTF-8-BOM”）再保存
- VS Code：务必用
Save with Encoding → UTF-8（注意不是“UTF-8 with BOM”）
HTTP 响应头 Content-Type 覆盖了 meta
当页面通过 http:// 或 https:// 访问时，服务器返回的 Content-Type 响应头优先级高于 meta。如果它写着 charset=gbk，哪怕 meta 写得再标准也没用。
- Chrome DevTools → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers → 找
Content-Type值 - Nginx：配置里加
charset utf-8;（注意小写，且不能写在add_header Content-Type里，会重复） - Apache：
.htaccess中加AddDefaultCharset UTF-8 - Express.js：
res.set("Content-Type", "text/html; charset=utf-8")必须在res.send()或res.render()之前调用
file:// 协议下只能靠 meta，BOM 反而坏事
本地双击打开 HTML（即 file:// 协议），没有 HTTP 响应头，全靠 meta 和文件编码。这时候 BOM 不仅没用，还容易让某些工具（比如旧版 Nginx、Webpack 插件）误判为非法字符，甚至破坏 JS/CSS 加载。
- 确认文件无 BOM 后，把
放到的最开头，前面**不能有任何字符**（包括空格、换行、
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
