必须统一HTML文件编码、<meta charset>声明和HTTP响应头为UTF-8（无BOM），缺一不可；任一错配（如文件存为GBK却写<meta charset="UTF-8">）即导致中文乱码，BOM会干扰解析并引发Node.js报错或平台拒收。
必须在 HTML 文件保存编码、<meta charset> 声明、HTTP 响应头三者全部统一为 UTF-8，缺一不可；任一环节错配（比如文件存为 GBK 但写了 <meta charset="UTF-8">），中文就会乱码。
确认并保存 HTML 文件为纯 UTF-8（无 BOM）
VS Code 默认保存为 UTF-8，但可能误选 “UTF-8 with BOM”。BOM（EF BB BF）会卡在文件开头，导致 Node.js 的 res.sendFile() 报 Invalid character，微信 HTML Publisher 直接拒收，部分旧版 IE 无法识别 <!DOCTYPE html>。
- 在 VS Code 中：点击右下角编码显示（如 “GBK” 或 “UTF-8 with BOM”）→ 选 “Save with Encoding” → 选
UTF-8（注意不是 “UTF-8 with BOM”） - 验证是否干净：终端运行
xxd -l 4 yourfile.html，输出首行不应含ef bb bf - Sublime Text 同理：File → Save with Encoding → UTF-8
<meta charset> 必须写对位置和大小写
这个标签只在 <head> 内、且必须位于所有其他标签（包括 <title>、<script>）之前，否则浏览器可能已按默认编码（如 Windows 下的 GBK）解析了前面的内容，再改也晚了。
- 正确写法：
<meta charset="UTF-8">（注意是UTF-8，不是utf8或utf-8—— 后两者在部分旧环境 fallback 失效） - 错误写法示例：
<meta charset="utf8">、<meta http-equiv="Content-Type" content="text/html; charset=utf-8">（HTML5 已不推荐该写法） - 必须紧贴
<head>开始：前 1024 字节内不能有其他内容（含空格、注释、BOM）
检查 HTTP 响应头中的 Content-Type
当页面通过 http:// 或 https:// 加载时，服务器返回的 HTTP 响应头中 Content-Type 的优先级高于 <meta charset>。若头里写的是 charset=GBK，哪怕 <meta> 写对了也没用。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- Chrome/Firefox 按 F12 → Network → 刷新 → 点 HTML 请求 → 查看 Response Headers → 确认
Content-Type: text/html; charset=utf-8 - Nginx 配置加：
charset utf-8;（在server或location块内） - Apache 配置加：
AddDefaultCharset UTF-8（在.htaccess或虚拟主机配置中） - Node.js/Express 中：在
res.send()前加res.set("Content-Type", "text/html; charset=utf-8")
本地双击打开（file://）时的特殊处理
这种场景下没有 HTTP 头，浏览器完全依赖 <meta charset> 和系统默认编码。Windows 默认用 GBK 解析，所以如果文件存为 UTF-8 但没写 <meta charset>，双击打开必乱码。
- 此时
<meta charset="UTF-8">是唯一救命稻草，且必须存在、位置正确、无拼写错误 - 开发阶段尽量避免双击测试，改用
npx serve、Vite、Webpack Dev Server 等本地 HTTP 服务——它们默认发 UTF-8 响应头，更贴近真实部署环境 - GitHub Pages、Vercel、Netlify 等平台默认 UTF-8，但上传带 BOM 的文件会被识别为“非标准 UTF-8”，可能触发奇怪渲染降级
最容易被忽略的是：文件编码、<meta>、HTTP 头三者看似独立，实则构成一个强依赖链。改其中一处，必须同步核对另外两处；调试时先用 xxd 和 Network 面板分别验文件头和响应头，比反复修改 HTML 更快定位问题根源。
