根本原因是文件实际编码、<meta charset>声明与HTTP响应头三者不一致；必须统一为UTF-8（无BOM），且<meta charset="UTF-8">须置于<head>最前，无BOM干扰，HTTP头优先级高于meta标签。
HTML文件在不同系统、编辑器或浏览器里乱码，根本原因不是“没写meta charset”，而是字符编码声明和实际文件存储编码不一致，或者HTTP响应头与HTML内部声明冲突。只要这两层对不上，哪怕写了UTF-8也照样出错。
怎么确认你的HTML文件真正是UTF-8编码
很多人用VS Code打开HTML文件，右下角显示“UTF-8”，就以为万事大吉——但那只是编辑器的“猜测”。真实编码由文件开头的字节决定。
- 用二进制查看器（如VS Code插件Hex Editor）检查文件开头：UTF-8 without BOM应以
EF BB BF开头；有BOM则多这三个字节，但部分旧Android WebView或IE会误判为内容 - 命令行快速验证：
file -i your-file.html（Linux/macOS）或certutil -hashfile your-file.html SHA1配合字节比对（Windows） - 如果用PHP/Node.js等后端生成HTML，确保输出前调用
header("Content-Type: text/html; charset=UTF-8")，且模板文件本身也是UTF-8 without BOM
meta charset和HTTP头冲突时谁赢
HTTP响应头中的Content-Type优先级永远高于<meta charset>。即使HTML里写了<meta charset="UTF-8">，如果服务器返回Content-Type: text/html; charset=GBK，浏览器仍按GBK解析——直接乱码。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 本地双击打开HTML文件（
file://协议）时，无HTTP头，此时只认<meta charset>，必须顶格写在<head>最前面 - Nginx/Apache配置中，
AddDefaultCharset UTF-8可能覆盖你PHP里设的header，要关掉 - React/Vue等构建产物部署到CDN时，检查CDN是否强制注入了错误charset头（常见于国内某些CDN默认GBK）
跨平台编辑器保存时的隐藏陷阱
Windows记事本、某些国产编辑器（如Notepad++未手动选编码）、甚至部分IDE在“另存为”时，默认用系统区域设置编码（比如中文Windows是GBK），而非UTF-8。
立即学习“前端免费学习笔记（深入）”；
- VS Code：右下角点击编码名称 → 选“Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM） - Sublime Text：File → Save with Encoding → UTF-8
- 禁止用Windows记事本直接编辑HTML，它无法可靠保存UTF-8 without BOM
- Git用户注意：
git config --global core.autocrlf true在Windows上可能导致换行符干扰，但不会改编码；真正危险的是git config --global core.safecrlf true被禁用后，GBK文件被Git当UTF-8提交
最容易被忽略的一点：HTML文件本身编码正确、meta和HTTP头也一致，但引入的外部JS/CSS文件用了GBK编码，浏览器加载时会按HTML声明的UTF-8去解，结果JS语法报错或CSS样式失效——跨平台兼容从来不是单个文件的事，而是整个资源链的编码对齐。
