根本原因是手机通过 file:// 协议打开 html 时忽略 ，而依赖文件 bom 标记；无 bom 的 utf-8 文件在 ios 默认按 latin-1 解析、android 可能 fallback 到 gbk，导致中文乱码。
手机打开 HTML 文件中文乱码，根本原因不是“网页写错了”，而是手机加载时没按 UTF-8 解码——哪怕你代码里写了 <meta charset="UTF-8">，它也可能被忽略。
为什么 <meta charset="UTF-8"> 在手机上经常失效
这个标签只在通过 HTTP 协议（http:// 或 https://）加载页面时才可靠；而用文件系统直接打开（file:// 路径，比如微信转发的本地 HTML、邮件附件、iCloud 下载后点开），iOS 和 Android 都不读取 <meta>，而是依赖文件本身的编码和 BOM 标记。
- iOS Safari 对无 BOM 的 UTF-8 文件，默认按 Latin-1（ISO-8859-1）解析，中文直接变方框或问号
- Android Chrome 有些版本会 fallback 到系统默认编码（如 GBK），尤其在微信内嵌浏览器中更常见
- 即使写了
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，file://场景下依然无效
必须给 HTML 文件加 BOM 才能被手机正确识别
VS Code、Sublime 等编辑器默认保存为 “UTF-8” 是无 BOM 的，这在桌面浏览器里通常没问题，但在手机上就是乱码根源。你需要强制保存为 “UTF-8 with BOM”：
- VS Code：右下角点击编码名称（如 “UTF-8”）→ 选 Save with Encoding → 选
UTF-8 with BOM - Sublime Text：菜单
File → Save with Encoding → UTF-8（注意：Sublime 的 “UTF-8” 实际就是带 BOM 的，不用额外找） - 确认是否成功：用终端执行
xxd -l 3 filename.html，开头显示ef bb bf即为 BOM 存在 - ⚠️ 别用 Notepad++ 直接“转为 UTF-8-BOM”再保存——它可能把已有内容二次编码，导致双乱码
绕过 file:// 限制：用本地 HTTP 服务临时调试
如果你控制 HTML 文件生成过程（比如 Python 脚本导出、Node.js 生成报告），最稳的方式是避免 file:// ——起一个极简 HTTP 服务，让手机访问 http://192.168.x.x:8000/report.html：
- Python 3：
python3 -m http.server 8000（确保当前目录含 HTML，且文件已存为 UTF-8 with BOM） - Node.js：
npx http-server -p 8000（同样要求文件带 BOM） - 此时
<meta charset="UTF-8">生效，且服务器响应头自动带Content-Type: text/html; charset=UTF-8 - 手机和电脑在同一 WiFi 下，用手机浏览器访问电脑 IP 即可，完全规避 file:// 的各种玄学
微信、钉钉等 App 内打开仍乱码？检查它们的缓存和 MIME 类型
这些 App 内置 WebView 加载本地 HTML 时，有时会忽略 BOM，还可能错误地把文件当成了 text/plain：
- 在 HTML 文件同目录下加一个空的
.htaccess（仅对支持该机制的环境有效）或改后缀为.php并加 header：header('Content-Type: text/html; charset=utf-8'); - 更简单：把 HTML 压缩成 ZIP，发过去让对方解压后用系统浏览器打开（而非 App 内置浏览器）
- 终极验证：用 iOS “文件”App 找到该 HTML → 点击右上角 ··· → “在 Safari 中打开”——如果这里正常，说明是 App WebView 的兼容性问题，不是文件本身问题
BOM 是手机端 HTML 中文显示的硬门槛，不是可选项；而 file:// 场景下任何 meta 标签都是摆设——这点容易被忽略，但恰恰是 90% 本地 HTML 乱码的根因。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
