必须是第一个标签，因微信x5内核仅扫描前1024字节查找该标签，若前面有注释、、bom或空格即失效，fallback至gbk导致中文乱码、js语法错误及资源路径异常。
必须写 <meta charset="UTF-8">，且它得是 里的第一个标签，否则微信 X5 内核会 fallback 到 GBK，中文直接变乱码。
为什么 <meta charset="UTF-8"> 必须放在
微信 X5 内核解析 HTML 时，只扫描前 1024 字节找 <meta charset>。如果它前面有注释、<title></title>、BOM 或空格，就会跳过，转而用系统默认编码（Windows 下是 GBK）。结果就是：<title></title> 里中文显示为 “”，<script></script> 里中文字符串报 Uncaught SyntaxError: Invalid or unexpected token，连 <link rel="stylesheet"> 的 href 含中文路径都会出错。
无序列表：
-
<title>测试页</title> <meta charset="UTF-8">→ 失效（<title></title>挡住了） -
<!-- 注释 --><meta charset="UTF-8">→ 失效（注释占了前几字节） -
<meta charset="utf8">→ 失效（utf8不是标准值，X5 不认） - 正确写法：
<meta charset="UTF-8"> <title>测试页</title>
文件保存必须是 UTF-8（无 BOM），不是“UTF-8 with BOM”
VS Code 默认保存为 “UTF-8 with BOM”，但 BOM（EF BB BF）会吃掉前 3 字节，导致 X5 扫不到 <meta charset>。更糟的是，某些低版本 X5 会把 BOM 当作非法字符，直接中断 HTML 解析，页面白屏且控制台静默——你根本看不到任何报错。
无序列表：
- 用 VS Code：保存时选
Save with Encoding→UTF-8（明确不勾选 “with BOM”） - 用 Sublime Text：菜单
File → Save with Encoding → UTF-8 - 验证方式：Linux/macOS 运行
xxd -l 4 index.html，输出应以3c 68 74 6d（即<htm>）开头；若看到 <code>ef bb bf，说明还有 BOM - 别信编辑器右下角显示的 “UTF-8”，它可能只是声称，实际保存仍为 GBK（尤其从旧项目复制粘贴时）
HTTP 响应头里的 charset 优先级高于 <meta>，但微信里常被忽略
当 HTML 通过 HTTP 加载（如 https://xxx.com/index.html），服务端返回的 Content-Type: text/html; charset=UTF-8 理论上比 <meta> 更权威。但在微信 X5 中，这个 header 经常被内核丢弃或覆盖——尤其是使用 CDN、反向代理或静态托管平台（如 GitHub Pages）时，header 可能没传、写错大小写（如 charset=utf8），或被微信中间层劫持。
无序列表：
- Nginx 配置要写
charset utf-8;（小写，带短横，不能写UTF-8或charset=UTF-8） - Express.js 中用
res.set('Content-Type', 'text/html; charset=utf-8')，别只靠res.sendFile()（它不自动设 charset） - GitHub Pages、Vercel 等平台虽默认 UTF-8，但一旦你上传了带 BOM 的文件，它们照样吐乱码——
<meta>和文件编码必须双重一致 - 真机调试时，在 Chrome DevTools 的 Network 标签页看 HTML 请求的
Response Headers，确认content-type字段含charset=UTF-8，且 Preview 标签页里中文能正常渲染
外链 JS/CSS 文件也得是 UTF-8，且不能依赖 charset 属性
HTML5 已废弃 <script charset="UTF-8"></script> 和 <link charset="UTF-8">。X5 内核完全不读这两个属性，它只按 HTTP 响应头或文件自身编码解析。如果外链 JS 里有中文注释或字符串，而 JS 文件实际存为 GBK，那就算 HTML 本身全对，也会在执行时报错或显示乱码。
无序列表：
- 所有
.js、.css文件必须单独保存为 UTF-8（无 BOM） - 避免在 JS 里写
document.write('<div>你好</div>')—— X5 对 document.write 的编码处理极不稳定 - AJAX 提交表单时，
<form accept-charset="UTF-8"></form>在 X5 中基本无效；稳妥做法是服务端统一按 UTF-8 解码，前端用encodeURIComponent()编码中文字段 - Webpack/Vite 等构建工具生成的 HTML，要检查插件是否自动注入了错误的
<meta>，或把源文件编码误判为 GBK
最易被忽略的一点：微信开发者工具里的编码表现和真机完全不一致——它用的是模拟 Chromium，不走 X5 渲染链路。所有编码问题，必须用“文件传输助手发本地 index.html”在 vivo、华为、iPhone 真机上测，否则等于没测。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
