HTML乱码问题根源在于编码声明与实际编码不一致及HTTP响应头优先级更高。需确保编辑器保存为UTF-8无BOM、<meta charset="UTF-8">位于<head>最前且无BOM/空格/注释，并检查服务器是否发送了冲突的Content-Type响应头。
直接改 <meta charset="UTF-8"> 或编辑器保存编码就能解决，不用查半天服务器配置。
VS Code 右下角显示 GBK 就别硬写 UTF-8
编辑器右下角显示的编码（如 “GBK”）必须和 <meta charset> 一致，否则浏览器按声明解码，实际字节却是另一套规则，必然乱码。
- 右下角点编码名 → 选 “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM） - 切勿用 Windows 记事本另存为 “UTF-8”，它默认加 BOM，会干扰
<meta>解析 - Sublime / Notepad++ 同理：选 “UTF-8”，确认状态栏显示 “UTF-8”，不是 “UTF-8-BOM”
- 验证方式：
file -i index.html（Linux/macOS）或 PowerShell 中Get-Content index.html -Encoding Byte | Select -First 3，无 BOM 应无ef bb bf
<meta charset> 必须放在 <head> 最前面
浏览器只扫描前 1024 字节找 <meta charset>，如果开头有空格、注释、BOM 或其他字符，这个标签就失效，退回到系统默认编码（如 ISO-8859-1 或 GBK）。
- 确保
<meta charset="UTF-8">是<head>内第一个有效标签 - 删掉
<head>前所有空格、换行、<!--注释、BOM 字节 - 不要写
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，HTML5 只认<meta charset> - 避免 AI 生成模板在
<meta>前塞一堆不可见字符或注释
HTTP 响应头 Content-Type 优先级高于 <meta>
只要服务器返回了带 charset 的 Content-Type 头，比如 text/html; charset=gbk，浏览器就完全忽略 HTML 里的 <meta charset>，直接按响应头解码。
立即学习“前端免费学习笔记（深入）”；
- 本地双击打开（
file://协议）：只看<meta>和文件实际编码 - 用
python -m http.server或 Live Server 插件：默认不发charset头，<meta>生效 - Nginx：检查配置里有没有
charset gbk;这类硬编码指令，应改为charset utf-8; - Express：
res.set('Content-Type', 'text/html; charset=utf-8')必须在res.send()前调用 - 验证方法：F12 → Network → 刷新 → 点 HTML 请求 → 查 Response Headers 中的
Content-Type
PHP / Node.js 动态输出 HTML 时容易漏掉响应头
PHP 的 header() 和 Node.js 的 res.set() 如果没显式设置 charset，很多环境会默认发 text/html; charset=iso-8859-1，哪怕你写了 <meta charset="UTF-8"> 也没用。
- PHP：必须在任何输出前调用
header('Content-Type: text/html; charset=utf-8');，且不能有 BOM（否则header()报错） - Node.js/Express：用
res.set('Content-Type', 'text/html; charset=utf-8')，别依赖res.sendFile()的默认行为 - PHP 模板（如 Twig/EJS）中写的
<meta>不影响响应头，得在 PHP 层统一控制 - 检查 PHP
default_charset配置，设为空或utf-8，避免覆盖手动 header
BOM 是最隐蔽的坑：它藏在文件开头看不见，却能让 <meta charset> 完全失效；而 HTTP 响应头一旦存在，就彻底接管解码权——这两点最容易被忽略，也最难排查。
