<meta charset="UTF-8">必须置于<head>开头且为第一个可解析元素，否则浏览器仅扫描前1024字节找不到该标签时，将回退至系统默认编码（如Windows的GBK）导致乱码；BOM、空格、注释或<script>前置均会使声明失效。
meta charset="UTF-8" 必须放在 <head> 开头、且是第一个可解析的元素，否则大概率失效。这不是“写了就行”的事，而是浏览器解析 HTML 时硬性规则：它只扫描前 1024 字节找这个标签，一旦被 BOM、空格、注释或 <script> 挡住，就直接 fallback 到系统默认编码（Windows 是 GBK）。
为什么 meta charset="UTF-8" 放对位置比写对还重要
浏览器不是等整个 HTML 加载完才看编码声明——它边下载边解析，前 1024 字节内没找到合法 meta charset，就放弃并按本地环境猜。常见踩坑点：
- 文件开头有 BOM（
ef bb bf），哪怕只是 VS Code 默认存的 “UTF-8 with BOM”，就会把meta推到第 4 字节之后，直接失效 -
<head>里写了注释<!-- 页面配置 -->或空行，导致meta不是第一个子节点 - 误写成
<meta charset="utf8">或<meta charset="UTF8">—— 只有"UTF-8"是标准值，大小写和连字符都不能错 - 同时存在
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，HTML5 已不推荐，反而可能干扰解析顺序
如何验证 HTML 文件实际保存为 UTF-8（无 BOM）
编辑器显示 “UTF-8” ≠ 文件实际是 UTF-8 编码。必须查字节：
- Linux/macOS：
xxd -l 4 index.html—— 若输出含ef bb bf，说明带 BOM；正常应从3c 68 74 6d（即<htm）开始 - PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3—— 输出239 187 191即 BOM - VS Code：右下角状态栏点击编码名 → 选 “Reopen with Encoding” → 试 GBK/ISO-8859-1 看是否乱码；确认后点 “Save with Encoding” → 选 “UTF-8”（**不勾选 “with BOM”**）
HTTP 响应头里的 charset 会覆盖 meta
当页面通过 HTTP 加载（http:// 或 https://），服务器返回的 Content-Type: text/html; charset=xxx 优先级高于 meta。这意味着：
立即学习“前端免费学习笔记（深入）”；
- 本地双击打开
file://时，完全依赖meta和文件编码，HTTP 头无效 - Nginx 默认不发 charset，需显式加
charset utf-8;（注意小写，不能写charset=UTF-8） - Apache 需在
.htaccess或虚拟主机配置中加AddDefaultCharset UTF-8（大小写敏感） - Express.js 中用
res.set('Content-Type', 'text/html; charset=utf-8')，不能只靠res.sendFile()
<script> 和 <link rel="stylesheet"> 的编码也得统一
外部 JS/CSS 文件若本身是 GBK 编码，即使 HTML 声明了 UTF-8，也会在加载时报 Uncaught SyntaxError: Invalid or unexpected token。验证方法：
- 终端执行
file -i app.js（Linux/macOS）或查看编辑器右下角编码标识 - JS 文件里出现中文变量名、字符串或注释，必须存为 UTF-8（无 BOM）
- 避免在 HTML 中给 script 标签加
charset属性（如<script charset="GBK">），这属于过时写法，且易引发兼容问题
真正容易被忽略的是：BOM 和 HTTP 响应头的优先级关系。很多人调通了 meta 就以为万事大吉，结果部署到 Nginx 后发现线上乱码——因为 Nginx 没配 charset，而浏览器 fallback 到了 GBK；或者反过来，Nginx 配了 charset utf-8，但 HTML 文件本身是 GBK 编码，meta 写着 UTF-8，结果字节流和声明打架，显示一堆 。
