根本原因是文件实际编码、meta声明、HTTP响应头三者未统一为UTF-8；须依次验证：编辑器中强制保存为UTF-8（无BOM），meta charset="UTF-8"置于head最前，服务器配置Content-Type: text/html; charset=utf-8。
HTML 文件出现中文乱码，**根本原因几乎总是编码不一致**：文件实际保存的字节序列、<meta charset> 声明、HTTP 响应头 Content-Type 三者中至少有一项没对齐。修复不是“试一试”，而是按顺序验证这三项是否统一为 UTF-8。
检查 HTML 文件实际保存编码（VS Code/Sublime 最常出错）
编辑器默认编码 ≠ 文件当前编码。很多乱码是编辑器“以为”文件是 GBK，却用 UTF-8 解读，结果把 中（UTF-8 字节 E4 B8 AD）错当成三个 GBK 字符显示成 ä¸。
- 在 VS Code 中右下角查看当前编码（如显示
GBK或UTF-8 with BOM），点击它 → 选Save with Encoding→ 强制选UTF-8（不含 BOM） - Sublime Text：菜单
File → Save with Encoding → UTF-8 - 用命令行确认：Linux/macOS 运行
file -i filename.html；Windows PowerShell 运行Get-Content -Encoding UTF8 -Raw filename.html | Out-Null（不报错即大概率是 UTF-8） - 避免 BOM：
xxd filename.html | head -n1查看开头是否为ef bb bf，有则删掉——BOM 在 Node.js、PHP、Nginx 静态服务中易引发头部输出异常
验证 <meta charset> 是否存在且位置正确
<meta charset="UTF-8"> 必须出现在 <head> 内，且越靠前越好（最好第一行）。它只对 file:// 协议或 HTTP 响应头缺失时起作用；如果服务器已发 Content-Type: text/html; charset=gbk，这个 meta 就被忽略。
- 必须写成
<meta charset="UTF-8">，不要写utf8、utf-8（小写连字符或缺位都可能被部分旧浏览器忽略） - 不能写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 这是过时写法，且在 HTML5 中语义不准确 - 确保它没被注释掉、没被 JS 动态删掉、没混在
<title>或<script>后面（某些模板引擎会把动态内容插到 head 开头前） - 用浏览器开发者工具 →
Elements标签页，展开<head>，肉眼确认该标签真实存在且未被破坏
抓包看 HTTP 响应头 Content-Type 是否覆盖了 meta
本地双击打开 HTML 文件（file://）时，浏览器只认 <meta charset>；但通过 HTTP 服务（Nginx/Apache/Express）访问时，服务器返回的 Content-Type 响应头优先级更高。很多人改了 meta 却没改服务器配置，白调。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 打开浏览器 DevTools →
Network→ 刷新页面 → 点击 HTML 请求 → 查Response Headers中的Content-Type - 常见错误值：
text/html; charset=iso-8859-1（Apache/Nginx 默认）、text/html; charset=gbk（老旧 PHP 项目）、甚至空值 - Nginx：在
server或location块中加charset utf-8;（注意是小写utf-8，不是UTF-8） - Apache：在
.htaccess或虚拟主机配置中加AddDefaultCharset UTF-8 - Express：用
res.set('Content-Type', 'text/html; charset=utf-8')显式设置，别依赖res.sendFile()的默认行为
特殊场景：模板引擎或动态生成 HTML
Thymeleaf、EJS、Jinja2 等模板渲染后，<meta charset> 可能被插入到错误位置，或模板本身保存编码不对，导致最终 HTML 混合编码。
- 确认模板文件（如
index.html）本身是 UTF-8 编码保存（同第一点） - Thymeleaf：在 Java 配置中设
templateResolver.setCharacterEncoding("UTF-8") - EJS：启动时传参
encoding: 'utf8' - Tomcat：在
server.xml的Connector中加URIEncoding="UTF-8" useBodyEncodingForURI="true"，否则 URL 参数和表单提交也会乱 - 数据库字段、JSON 接口返回值也得是 UTF-8——前端 HTML 再规范，后端吐出的是 GBK 字节，照样乱
真正容易被忽略的点：**乱码一旦发生，原始字节可能已被错误解码覆盖**。比如用 GBK 打开 UTF-8 文件再保存，中 就永久变成 ä¸ 了。所以排查时务必先备份原文件，所有“转换”操作都在副本上做，并用十六进制编辑器（如 xxd）比对字节变化，而不是只看屏幕显示。
