<meta charset="UTF-8">必须置于<head>开头、任何非ASCII内容（如<title>、注释、BOM、空行）之前，否则浏览器仅扫描前1024字节且只识别ASCII字符，一旦遇到中文、emoji或BOM即停止解析，fallback至GBK/ISO-8859-1导致乱码或JS报错。
meta charset="UTF-8" 必须写在 <head> 开头、任何非 ASCII 内容（包括 <title>、注释、空行、BOM）之前，否则浏览器可能 fallback 到系统默认编码（如 Windows 的 GBK），直接导致乱码、表单提交乱码、JS 报 Invalid or unexpected token。
为什么 meta charset="UTF-8" 放错位置就失效
浏览器解析 HTML 时只扫描前 1024 字节找 meta charset，且仅识别 ASCII 范围内的字符。一旦开头出现：
- 中文
<title>首页</title>—— 已超 ASCII，跳过识别 - 注释
<!-- 页面标题 -->—— 注释内容含非 ASCII，整行不被当作 ASCII 区域 - BOM（
EF BB BF）在<!DOCTYPE html>前 —— 某些旧版 IE 和部分 WebView 无法跳过 BOM 识别meta - 空行或缩进空格后跟
<meta charset="UTF-8">—— 空行本身不算 ASCII “有效前置”，实际起始偏移变大
结果就是：浏览器没在前 1024 字节内“看到”合法的 meta charset，转而用 GBK 或 ISO-8859-1 解析后续所有字节，中文全变 ，emoji 直接报错。
VS Code / Notepad++ 保存文件时必须选 UTF-8 with BOM
很多编辑器默认保存为纯 UTF-8（无 BOM），但 BOM 在这里不是“可有可无”的标记 —— 它是让 meta charset 能被早期解析器（尤其是某些 Node.js 测试环境、jsdom、微信 WebView）稳定识别的关键缓冲。实测对比：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- VS Code：保存时选 Save with Encoding → UTF-8 with BOM（不能只选 “UTF-8”）
- Notepad++：编码 → 转为 UTF-8-BOM 格式（菜单里明确带 “BOM” 字样）
- Sublime Text：File → Save with Encoding → UTF-8
- Linux/macOS 终端验证：
file -i index.html应返回charset=utf-8；PowerShell：Get-Content index.html -Encoding Byte | Select -First 3应输出239, 187, 191
HTTP 响应头比 meta 更优先，但常被忽略
Content-Type: text/html; charset=UTF-8 响应头的优先级高于 meta charset。如果服务器返回的是 charset=GBK 或压根没带 charset，那 HTML 里写十遍 meta 都没用。
- Apache：
.htaccess中加AddDefaultCharset UTF-8或Header set Content-Type "text/html; charset=UTF-8" - Nginx：
server或location块中加charset utf-8;（注意不是AddDefaultCharset） - Express：
res.set('Content-Type', 'text/html; charset=UTF-8')必须在res.send()之前调用 - 静态托管（Vercel/Netlify/GitHub Pages）：默认发
charset=utf-8，无需额外配置；但若本地调试用file://协议，则完全依赖meta和文件编码
验证是否真正生效的三个硬指标
别只看页面显示正常 —— 很多乱码在特定路径下才暴露。必须同时满足以下三点才算真正搞定：
- Chrome DevTools → Network → 刷新 → 点开 HTML 请求 → Response Headers 中
Content-Type值包含charset=utf-8 - 控制台执行
document.characterSet，返回值必须是"UTF-8"（注意大小写） - 用
textarea输入中文并提交表单，后端收到的$_POST或req.body字段值是原始中文，而非乱码字节序列（如%E4%BD%A0%E5%A5%BD是 URL 编码，正常；浣是 GBK 解 UTF-8 字节，失败）
最容易被绕过的点是：编辑器存对了、meta 位置也对，但服务器响应头没配，或者本地双击打开 HTML 文件（file:// 协议），此时浏览器根本收不到 HTTP 头，全靠 meta 和 BOM —— 这时候 BOM 就成了最后一道防线。
