必须置于 最开头，前面不能有任何字符（含bom、注释、空格或），否则移动端webview可能fallback至iso-8859-1等默认编码，导致中文乱码；因其仅扫描前1024字节查找该标签，且对bom和位置敏感，而file://协议下无http响应头时更易失效。
meta charset="UTF-8" 必须放在 最开头，且前面不能有任何字符（包括 BOM、注释、空格或 <script></script>），否则移动端 WebView 可能 fallback 到系统默认编码（如 Android 默认 ISO-8859-1，iOS 某些旧版本也类似），直接导致中文乱码。
为什么移动端比桌面端更容易出编码问题
移动端 WebView（尤其是 Android 4.4+ 的 System WebView、iOS UIWebView/WKWebView）对 HTML 解析更严格：它只读取前 1024 字节来查找 meta charset；一旦这范围内没找到有效声明，就立即按 HTTP 响应头或系统默认编码解码——而很多静态托管服务（如 GitHub Pages、Vercel）虽默认发 UTF-8，但若你本地文件存成了 GBK 或带 BOM 的 UTF-8，响应头和文件内容就错位了。
- Android Chrome WebView 在未识别到
meta charset时，可能用 ISO-8859-1 解码 UTF-8 字节流，把一个汉字变成三个乱码符号 - iOS WKWebView 对 BOM 更敏感：如果
<meta charset="UTF-8">前有 BOM（EF BB BF），它可能跳过该标签，转而信任响应头——但file://本地调试时响应头为空，彻底失效 - 微信内置浏览器、QQ 浏览器 X5 内核曾长期存在 meta 解析 bug，必须确保
<meta charset>是中第一个子节点
怎么验证你的移动端页面编码真正生效
别只看浏览器预览是否“看起来正常”——很多乱码在 DOM 渲染后仍能凑合显示，但 JS 操作会暴雷（比如 document.title 取出来是乱码、fetch() 返回的文本解析失败）。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用 Chrome DevTools 连真机，在 Network → HTML 请求 → Response Headers 看
Content-Type是否含charset=UTF-8 - 同个请求点开 Response 标签页，用 Ctrl+U 查看源码，确认
<meta charset="UTF-8">确实在开头，且前面无空行、无注释、无 BOM - 在控制台执行
document.characterSet和document.inputEncoding，两个都必须返回"UTF-8"（不是"utf8"或"UTF8"） - 用
xxd -l 3 index.html检查文件头：输出不含ef bb bf才算无 BOM
VS Code / 编辑器里最容易踩的坑
VS Code 新建文件默认是 UTF-8，但打开一个已有 GBK 文件后，它会自动识别并以 GBK 编码加载——此时你敲 <meta charset="UTF-8">，保存时若没手动选 “Save with Encoding → UTF-8”，实际存的还是 GBK 字节，浏览器用 UTF-8 解就必然乱码。
- 每次保存 HTML 前，右下角状态栏确认编码显示为
UTF-8（不是GBK、ISO-8859-1或UTF-8 with BOM） - 禁用插件如 “Auto Rename Tag” 在
插入空行或注释——它们可能把meta推到第二位 - Webpack/Vite 项目中若用
html-webpack-plugin，检查其template文件本身是否 UTF-8 无 BOM；插件生成的 HTML 若被二次处理（如 i18n 替换），要确保替换逻辑不污染编码声明位置
最隐蔽的问题往往不在 HTML 本身，而在配套资源：JS 文件若存为 GBK，alert("提交成功") 就会报 Uncaught SyntaxError: Invalid or unexpected token；CSS 里的中文注释同理。编码一致性是全链路的事，从编辑器保存那一刻就开始了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
