必须是内第一个非空白、非注释子元素，浏览器仅扫描前1024字节查找该标签，若被bom、空格、注释或等阻挡即失效，回退系统默认编码（如windows下gbk）导致中文乱码。
meta charset声明位置不对，浏览器直接忽略
浏览器在解析 HTML 前 1024 字节时就决定用什么编码解码，<meta charset="UTF-8"> 如果被空格、BOM、注释或 <title></title> 之类标签挡在后面，它就失效。常见现象是本地双击打开正常，但通过服务器访问就乱码——因为服务器响应头没覆盖，而浏览器只看了开头几百字节。
必须确保：
- 它是 内第一个非空白、非注释的子元素
- 前面不能有 BOM（ef bb bf）、空行、HTML 注释（<!-- -->）或任何不可见字符
- 不要写成 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，老式写法兼容性差且易被忽略
文件实际编码 ≠ meta 声明的编码
VS Code 右下角显示 “GBK” 却写了 <meta charset="UTF-8">，等于告诉浏览器“请用 UTF-8 解这串 GBK 字节”，结果必然乱码。尤其 Windows 编辑器默认保存为 GBK 或 ANSI，一保存就埋雷。
验证和修复方法：
- 用 xxd yourfile.html | head -n 1 查看前几字节：含 ef bb bf 就是带 BOM 的 UTF-8，需转为无 BOM
- VS Code：Ctrl+Shift+P → “Save with Encoding” → 选 UTF-8（不是 UTF-8 with BOM）
- Notepad++：菜单栏“编码” → “转为 UTF-8 编码”（不是“UTF-8-BOM”）
- Sublime Text：“File” → “Save with Encoding” → “UTF-8”
HTTP 响应头 Content-Type 覆盖了 meta 声明
服务器返回的 Content-Type: text/html; charset=gbk 或干脆没带 charset 子句，会强制覆盖 <meta charset>。这是线上环境最隐蔽的乱码原因——F12 → Network → 找 HTML 请求 → Headers → Response Headers 里看 Content-Type 值。
对应配置：
- Nginx：在 server 或 location 块加 charset utf-8;（注意小写，不能写 UTF-8）
- Apache：.htaccess 里加 AddDefaultCharset UTF-8
- Node.js（Express）：res.setHeader('Content-Type', 'text/html; charset=utf-8')
- Python（Flask）：return Response(html, mimetype='text/html; charset=utf-8')
外部资源（CSS/JS/JSON）引入时也用了错误编码
即使 HTML 本身没问题，<link rel="stylesheet" href="style.css"> 或 fetch('/data.json') 加载的文件若保存为 GBK 或带 BOM 的 UTF-8，其中的中文照样乱码。浏览器对 CSS/JS 的编码识别更弱，基本依赖 HTTP 响应头或 BOM。
排查要点：
- 检查所有 .css、.js、.json 文件是否同样用无 BOM UTF-8 保存
- 确保 Web 服务器对这些后缀也返回 charset=utf-8（Nginx 中可配 types { text/css css; application/javascript js; } + 全局 charset）
- JSON 接口必须返回 Content-Type: application/json; charset=utf-8，否则 jQuery.ajax 或 fetch 可能误判
真正卡住人的往往不是 <meta charset> 写没写，而是它和文件存储、HTTP 头、外部资源四者之间有一处不一致。每次乱码，按顺序查这四点，95% 能当场定位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
