HTML中文乱码本质是文件编码、声明、HTTP响应头三者不一致所致；必须统一为UTF-8（推荐无BOM），且须位于内前1024字节且无BOM/空格/注释干扰，HTTP响应头Content-Type优先级更高，file://协议下则完全依赖文件编码与meta标签。
HTML 中文乱码不是单一环节出错，而是文件编码、<meta charset> 声明、HTTP 响应头三者不一致导致的。只要其中任一环是 GBK / ISO-8859-1 / UTF-8 with BOM 等非标准组合，浏览器就极大概率 fallback 到系统默认编码（Windows 是 GBK），显示为“锟斤拷”“”或方框。
VS Code 保存 HTML 文件时编码选错
VS Code 默认在 Windows 上用 UTF-8 with BOM 保存新文件，但一旦你手动选了 “GBK” 或 “UTF-8”（无 BOM）再编辑含中文的 HTML，就会埋下乱码隐患：
- 如果文件实际是 GBK 编码，但写了
<meta charset="UTF-8">，浏览器按 UTF-8 解码 GBK 字节，每个中文变两个乱码字符（如“测试”→“测试”） - 如果文件是 UTF-8（无 BOM），但 VS Code 状态栏显示 “GBK”，说明它误判了编码 —— 此时直接保存会把 UTF-8 字节当 GBK 写回，彻底损坏内容
- 解决方法：右下角点击编码名称 → 选 Reopen with Encoding → 手动选对原始编码（如 GBK）→ 再点右下角 → Save with Encoding → 选
UTF-8（推荐无 BOM） - 验证：保存后执行
file -i index.html（macOS/Linux）或Get-Content index.html -Encoding Byte | Select -First 3（PowerShell），输出不含ef bb bf即为无 BOM UTF-8
<meta charset> 位置或写法错误
这个标签必须出现在 开始后的前 1024 字节内，且不能被注释、空格、BOM 或其他字符挡住：
- 错误写法：
<meta charset="utf8">（缺横杠）、<meta charset="UTF8">（大小写不规范）、<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（HTML5 不推荐，且易与真实 HTTP 头冲突） - 常见干扰：在
前插入空行、BOM、XML 声明（<?xml version="1.0" encoding="UTF-8"?>）、AI 生成的注释块（如<!-- Generated by ... -->） - 正确位置示例：
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>页面标题</title> </head>
- 检查方式：用十六进制查看器（如
xxd -l 32 index.html）确认前几个字节是纯 ASCII，没有ef bb bf或00 00等异常开头
HTTP 响应头 Content-Type 覆盖 <meta>
当通过 http:// 或 https:// 访问时，服务器返回的 Content-Type 响应头优先级高于 <meta charset>。哪怕 HTML 里写了正确的声明，只要响应头是 text/html; charset=gbk，浏览器就强制用 GBK 解码：
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- Nginx：确保配置中写了
charset utf-8;（在http、server或location块内），不要用add_header Content-Type—— 那会重复 header 且可能被忽略 - Apache：在
.htaccess或虚拟主机配置中加AddDefaultCharset UTF-8 - Node.js/Express：在
res.send()前调用res.set('Content-Type', 'text/html; charset=utf-8')，注意不能写成charset=UTF8（缺横杠） - PHP：在任何输出前调用
header('Content-Type: text/html; charset=utf-8');，且确保该行前无空格、BOM 或 echo - 验证：F12 → Network → 刷新 → 点 HTML 请求 → 查看 Response Headers 下的
Content-Type值
本地双击打开（file:// 协议）时失效
用文件管理器双击 HTML 文件，走的是 file:// 协议，此时没有 HTTP 响应头，浏览器完全依赖 <meta charset> 和文件自身编码。但很多编辑器（尤其 Windows 下）默认保存为 UTF-8 with BOM，而 BOM 会卡在 <meta> 前面，导致浏览器跳过该标签：
- 现象：双击正常，但用 Live Server /
python -m http.server启的服务却乱码 —— 很可能是 BOM 干扰了<meta>解析 - 解决：统一用无 BOM UTF-8 保存，并确保
<meta charset="UTF-8">是内第一个有效标签 - 特别注意：Python 的
http.server默认不发 charset，即使 HTML 正确，也可能 fallback 到iso-8859-1；建议改用 VS Code Live Server 插件或明确设置响应头
最易被忽略的点是：BOM 不 visible，但会破坏 <meta charset> 的生效条件；而 HTTP 响应头一旦存在，<meta> 就只是 fallback。两者都得对，缺一不可。
