HTML中文乱码是编码链路多环节失效所致，必须确保文件存储（UTF-8无BOM）、meta声明（<head>首行唯一且为UTF-8）、HTTP响应头（Content-Type含charset=UTF-8）、服务器配置（Nginx/Apache/Express显式设UTF-8）及外部资源（CSS/JS同为UTF-8）全部对齐，任一环节偏差即导致乱码。
HTML中文乱码不是“修一下就能好”的小毛病，而是编码链路上多个环节协同失效的结果。只要任一环（文件存储、meta声明、HTTP响应头、服务器配置、外部资源）没对齐UTF-8，汉字就可能变成、é、æ 这类符号。
确认HTML文件实际编码是否为UTF-8（无BOM）
VS Code右下角显示的“UTF-8”不等于真实编码——它可能是“UTF-8 with BOM”，也可能只是编辑器猜错了。BOM（EF BB BF）会干扰浏览器识别meta charset，尤其在老版本IE或某些PHP环境中。
- Linux/macOS下用命令验证：
head -c 4 index.html | xxd，输出含ef bb bf即带BOM - Windows PowerShell验证：
Get-Content index.html -Encoding Byte | Select -First 3 - VS Code中按
Ctrl+Shift+P→ 输入“Save with Encoding” → 选UTF-8（注意：不带“with BOM”后缀） - Sublime Text保存时务必勾选“UTF-8”，取消“UTF-8 with BOM”选项
meta charset必须放在<head>最开头且唯一
这个标签不是“写了就行”，位置和数量都敏感。浏览器只扫描<head>前1024字节找charset，如果前面有注释、空行、BOM或JS代码，就可能错过。
- 必须是
<head>内第一个非空白节点，推荐紧贴<head>写：<head><meta charset="UTF-8"> - 删掉所有重复声明，比如同时存在
<meta charset="UTF-8">和<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> - 禁止写成
<meta charset="utf8">或<meta charset="UTF8">——只有UTF-8是W3C标准值 - 服务端渲染模板（如Thymeleaf、EJS）要确认
meta没被动态插入到其他内容之后
检查HTTP响应头中的Content-Type
本地双击打开HTML文件（file://协议）时，HTTP头无效，全靠meta；但一旦走Web服务器（Nginx/Apache/Express），响应头优先级高于meta。若头里写着charset=iso-8859-1，meta直接被无视。
立即学习“前端免费学习笔记（深入）”；
- Chrome开发者工具 → Network → 点开HTML请求 → Headers → Response Headers → 查
Content-Type - Nginx配置需显式加：
charset utf-8;（在http或server块内） - Apache需在
.htaccess或虚拟主机中加：AddDefaultCharset UTF-8 - Express中用
res.set('Content-Type', 'text/html; charset=utf-8')，不能只依赖res.sendFile()
CSS/JS等外部资源也要UTF-8一致
HTML页面正常，但内联<script>里的中文报错，或CSS注释变乱码？那大概率是app.js或style.css本身存成了GBK/ANSI。
- 用同上方法验证JS/CSS文件是否为UTF-8（无BOM）
- 确保
<script src="app.js"></script>和<link href="style.css">指向的文件编码与HTML一致 - Webpack/Vite等构建工具默认输出UTF-8，但若源文件是GBK，需在loader中显式指定
encoding: 'gbk'再转UTF-8 - PHP生成HTML时，若PHP文件含BOM，
header()会提前输出，导致Content-Type头失效
真正卡住人的从来不是单点问题，而是“我以为对了”的叠加：文件存成UTF-8 with BOM、meta写在第5行、Nginx没配charset、JS文件还是GBK——四个环节各自差一点，结果满屏。动手前先用xxd或VS Code编码切换功能看一眼真实字节，比猜半天快得多。
