根本原因是HTTP响应头中Content-Type的charset声明优先级高于meta标签，本地file://协议不依赖响应头。需检查F12 Network中HTML请求的Response Headers，确保Content-Type为text/html; charset=utf-8，并修正Nginx/Apache/Express/PHP等服务端配置及文件UTF-8无BOM编码。
为什么本地双击打开正常，一上线就乱码
根本原因不是代码写错了，而是 file:// 协议和 HTTP 协议处理编码的方式完全不同。本地双击时浏览器只看 <meta charset="utf-8"> 和文件实际编码；而上线后服务器会发 HTTP 响应头，它优先级高于 <meta> —— 如果响应头里没声明 charset=utf-8，或者写了 charset=gbk，哪怕 <meta> 写得再对也没用。
检查并修复 HTTP 响应头中的 Content-Type
这是上线乱码最常被忽略的一环。必须确认服务端返回的响应头里有且仅有正确的 Content-Type：
- F12 → Network → 刷新页面 → 点 HTML 请求 → 查 Response Headers 中的
Content-Type - 正确值应为：
text/html; charset=utf-8（注意是小写utf-8，不能是UTF8或utf8） - 如果看到
charset=gbk、charset=iso-8859-1，或压根没带charset参数，就是服务端配置问题 - 如果响应头里有多个
Content-Type（比如 Nginx 里误配了add_header Content-Type ...），浏览器可能取第一个或报错，务必删掉冗余项
按常见服务端类型修正配置
不同环境修复方式差异很大，不能只改 HTML：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
Nginx：在
http、server或location块中加一行charset utf-8;；不要用add_header Content-Type "text/html; charset=utf-8"，它会和 Nginx 自动加的冲突 -
Apache：在
.htaccess或虚拟主机配置中加AddDefaultCharset UTF-8；避免用Header set Content-Type手动覆盖 -
Express（Node.js）：必须在
res.send()之前 调用res.set('Content-Type', 'text/html; charset=utf-8')；放在console.log后面就晚了 -
PHP：在输出 HTML 前（任何
echo、print之前）调用header('Content-Type: text/html; charset=utf-8');
顺手验证 HTML 文件本身是否真为 UTF-8（无 BOM）
上线前很多人以为“VS Code 显示 UTF-8 就万事大吉”，但 Windows 下默认保存可能是 UTF-8 with BOM，BOM（EF BB BF）会卡在 <meta> 前面，导致浏览器跳过识别：
立即学习“前端免费学习笔记（深入）”；
- VS Code：右下角点击编码名称 → “Save with Encoding” → 选
UTF-8（**不是**UTF-8 with BOM） - Linux/macOS 终端验证：
head -c 4 index.html | xxd，输出不含ef bb bf才安全 - PowerShell 验证：
Get-Content index.html -Encoding Byte | Select -First 3，前三字节不是239, 187, 191 - Notepad++：编码 → 转为 UTF-8 编码 → 再“另存为”，确认状态栏显示“UTF-8”（无 BOM 标识）
响应头、文件编码、<meta charset> 这三者只要漏掉一个，上线就可能乱码；其中响应头最容易被当成“前端事”而忽略，但它恰恰是线上环境的决定性一环。
