<meta charset="UTF-8">必须置于<head>最开头，因浏览器仅扫描前1024字节查找该标签；若被注释、BOM、空格或<title>阻挡，将fallback至ISO-8859-1等默认编码，导致中文、emoji及JS字符串立即乱码且不可逆。
为什么必须放在最开头
浏览器解析 HTML 时，会在前 1024 字节内扫描 meta charset 标签；如果没找到，就回退到系统默认编码（如 ISO-8859-1 或 Windows-1252），导致中文、emoji、数学符号全部乱码成 或一堆问号。哪怕 <title></title> 里只写了一个“你”，只要它出现在 meta 前，那个“你”就已经被错误解码了，后续再声明也救不回来。
常见错误写法：<title>我的页面</title>
<meta charset="UTF-8"> —— 这个 title 中的中文在解析时已被当成了 Latin-1 字节流，meta 再生效也晚了。
-
meta charset必须是内第一个子节点（紧接开始标签之后） - 不能被
<script></script>、<style></style>、注释甚至空格和换行提前占用位置 - VS Code 默认保存为 “UTF-8 with BOM” 时，BOM（
EF BB BF）会插在DOCTYPE前，导致部分老浏览器忽略meta，应手动选 “UTF-8”（无 BOM）保存
charset 声明与 HTTP 响应头冲突时谁赢
HTTP Content-Type 响应头中的 charset 优先级高于 meta charset。比如服务器返回 Content-Type: text/html; charset=GBK，即使 HTML 里写了 <meta charset="UTF-8">，浏览器仍按 GBK 解析——结果就是 UTF-8 编码的文件被当 GBK 读，每个汉字显示为两个乱码字。
验证方式：curl -I your-page.html 查看响应头；或浏览器开发者工具 Network → Headers → Response Headers → Content-Type。
立即学习“前端免费学习笔记（深入）”；
- 开发时用本地文件（
file://协议）无 HTTP 头，完全依赖meta和文件实际编码，务必保持二者一致 - Nginx 配置中应显式加
add_header Content-Type "text/html; charset=utf-8";，避免依赖 mime.types 的默认值 - Node.js/Express 中设置
res.set('Content-Type', 'text/html; charset=utf-8')比靠meta更可靠
accept-charset 和 AJAX 请求里的 charset 隐患
表单提交和 AJAX 若不显式指定编码，可能沿用页面初始编码（ISO-8859-1）或浏览器 locale 编码（如 Windows-1252），导致中文字段在后端收到的是乱码字节，且无法还原。
例如：<form action="/submit"></form> 不加 accept-charset="UTF-8"，用户在中文 Windows 系统下输入“你好”，后端可能收到 %C4%E3%BA%C3（GBK URL 编码）而非标准 UTF-8 的 %E4%BD%A0%E5%A5%BD。
-
<form accept-charset="UTF-8"></form>是必须项，不能省略 - fetch 提交表单时，若用
application/x-www-form-urlencoded，需手动加headers: { 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8' } - JSON 请求（
application/json）本身无 charset 参数，但 body 必须是 UTF-8 编码字符串，否则 Node.js 的req.body会截断或报错
meta http-equiv="Content-Type" 已过时且有兼容风险
HTML5 明确推荐 <meta charset="UTF-8">，而 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 是 HTML4 遗留写法，现代构建工具（如 Vite、Webpack 插件）可能自动删除它，某些移动端 WebView 也不识别。
更麻烦的是：这个写法在部分旧版 IE 中会触发“双重编码检测”，若同时存在 http-equiv 和 charset 属性，行为不可预测；Safari 对它的支持也不稳定。
- 彻底弃用
http-equiv="Content-Type"，只用meta charset - 不要混用：
<meta charset="UTF-8"> <meta http-equiv="Content-Type" content="...">—— 多余且增加出错概率 - 如果服务端已通过 HTTP 头正确声明，
meta charset仍是必需的：它是 fallback，也是 SEO 和离线缓存场景下的唯一依据
最容易被忽略的一点：字符集声明不是“设了就完事”。它必须和编辑器保存编码、HTTP 响应头、表单提交编码、AJAX 请求头、后端接收逻辑这五者严格对齐。漏掉任意一环，乱码就会在某个环节悄然出现，而且往往只在特定系统、特定输入内容下才暴露。
