必须紧贴标签后、前1024字节内不能有任何非ascii字符（如中文、bom、注释），否则浏览器 fallback 至系统默认编码（windows为gbk，linux/macos为iso-8859-1）导致乱码；文件须实际保存为utf-8无bom，且http响应头content-type charset须与之统一，否则以响应头为准。
meta charset 必须放在 head 开头，且前 1024 字节内不能有非 ASCII 内容
浏览器只扫描 HTML 文件开头的前 1024 字节来找 <meta charset="UTF-8">，一旦这范围内出现非 ASCII 字符（比如中文 <title>我的页面</title>、emoji、BOM 或注释里的中文），就可能跳过识别，退而使用系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），导致乱码或 JS 报 Invalid or unexpected token。
正确写法是让 <meta charset="UTF-8"> 紧贴 标签后，前面**不能有任何内容**，包括空格、换行、注释、BOM 或中文字符：
<meta charset="UTF-8"><title>我的页面</title>
- 错例：
<title>我的页面</title> <meta charset="UTF-8">——<title></title>里的中文已超出 ASCII 范围，meta失效 - 错例：
<!-- 页面标题 --><meta charset="UTF-8">—— 注释含中文，同样失效 - 错例：
<meta charset="utf8">——utf8缺少连字符，不是 IANA 注册标准值，部分旧环境（如某些 WebView）会忽略
文件实际编码必须是 UTF-8，且推荐不带 BOM
<meta charset="UTF-8"> 只是声明，不改变文件本身。如果文件实际保存为 GBK，哪怕写了这个标签，浏览器仍按声明去解码，结果就是一堆乱码字节被强行当作 UTF-8 解析，显示为 或其他异常符号。
验证和修正方法：
- VS Code：右下角点击编码名称 → 选
Reopen with Encoding→ 尝试GBK，若中文正常显示，说明原文件是 GBK；再点Save with Encoding→ 选UTF-8（**不要选 “UTF-8 with BOM”**） - macOS/Linux 终端：
file -i index.html查 MIME 类型；head -c 4 index.html | xxd查前 4 字节，若输出ef bb bf表示含 BOM - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，若前三字节是239, 187, 191，即 BOM
BOM 在 UTF-8 中非必需，且可能干扰某些工具链（如 Webpack 的 html-webpack-plugin 会报 warning），还占前几个字节，挤占那关键的 1024 字节扫描空间。
HTTP 响应头 Content-Type 与 meta charset 冲突时，以响应头为准
当服务器返回 HTTP 响应头 Content-Type: text/html; charset=GBK 时，无论 <meta charset="UTF-8"> 写得多规范，浏览器都优先按响应头解析 —— 这是 RFC 7231 明确规定的优先级。
常见踩坑场景：
- 本地双击打开
file://协议 HTML 文件：无 HTTP 响应头，完全依赖meta和文件编码 - 开发服务器（如 vite dev server）默认发
charset=utf-8，但若配置错误或用了代理，可能覆盖为 GBK - 后端模板引擎（如 PHP、Java Spring）手动设置了
Content-Type头，却忘了同步改 meta 或文件编码
调试建议：打开浏览器 DevTools → Network → 点开 HTML 请求 → 查看 **Response Headers** 中的 Content-Type 值，确认是否与 meta 一致。不一致时，优先修复服务端响应头。
script 标签加载外部 JS 时，也要单独指定 charset
<meta charset="UTF-8"> 只影响 HTML 文档本身的解析，不影响通过 <script src="xxx.js"></script> 加载的外部 JS 文件。如果 JS 文件本身是 GBK 编码，而 HTML 声明了 UTF-8，浏览器仍会用 UTF-8 去读 JS，导致语法错误。
解决办法是显式声明脚本编码：
<script src="app.js" charset="UTF-8"></script>
注意：charset 属性在现代浏览器中已非必需（前提是 JS 文件 HTTP 响应头也带 charset=UTF-8），但对老旧环境或离线调试仍有效。更稳妥的做法是确保所有 JS/CSS/HTML 文件统一保存为 UTF-8 无 BOM，并由服务器统一发送正确的 Content-Type 头。
真正容易被忽略的点在于：很多人花大力气调好 HTML 的 meta charset，却没检查 JS 文件的实际编码和传输头 —— 结果页面标题不乱，但按钮点击没反应，控制台报一串看不懂的 Unexpected token，根源就在那一行 JS 里藏着一个未转码的中文注释。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
