乱码根源在于文件编码、html声明、http响应头三者未统一；必须确保html为utf-8无bom、位于首行无干扰，且响应头含charset=utf-8。
乱码不是“写了没 charset”就能解决的问题，而是文件编码、HTML 声明、HTTP 响应头三者必须严丝合缝。只要其中一环错位或带干扰（比如 BOM、空格、注释），浏览器就会 fallback 到 GBK 或 ISO-8859-1，中文立刻变 éø¥ 或方框。
怎么确认 HTML 文件真实编码？别信 VS Code 右下角
VS Code 显示 “UTF-8”，只代表它当前“猜”这个文件是 UTF-8，不代表它真是。Windows 下用记事本保存过、从邮件拖进来的 HTML，十有八九是 GBK，但编辑器照样显示 UTF-8。
- 在 VS Code 中按
Ctrl+Shift+P→ 输入Reopen with Encoding→ 选GBK或GB2312，如果中文突然正常，说明文件实际就是 GBK - Sublime Text：菜单
File → Reopen with Encoding → GB2312 - Linux/macOS 终端执行：
file -i yourfile.html，若输出charset=gbk或charset=us-ascii（实为检测失败），就别再信编辑器右下角了
怎么保存为真正无 BOM 的 UTF-8？
BOM（EF BB BF）会占据文件开头三个字节，导致浏览器扫描 <meta charset="UTF-8"> 时偏移失效——哪怕你写对了，它也找不到。
- VS Code：
Ctrl+Shift+P→Save with Encoding→ 选UTF-8（注意不是UTF-8 with BOM） - Notepad++：菜单
编码 → 转为 UTF-8 无 BOM 格式 - 验证是否真去 BOM：
head -c 3 yourfile.html | xxd，输出不含ef bb bf才算成功
为什么 写对了还是乱码？
它必须是 开始后第一个可解析的标签。前面哪怕一个空格、换行、<!-- 注释 --> 或 <script></script>，都可能让浏览器跳过它，直接 fallback。
- 正确位置：
紧跟其后第一行就是<meta charset="UTF-8"> - 错误写法：
\n <!-- 编码声明 -->\n <meta charset="UTF-8">—— 注释已破坏优先级 - 大小写敏感：
utf8、UTF8、utf-8全部无效，只有"UTF-8"是标准值 - 别用
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">替代，HTML5 已不推荐，兼容性差
本地双击打开（file://）和 HTTP 服务（http://）行为完全不同
双击打开走 file:// 协议，HTTP 响应头完全失效，浏览器只认 <meta charset>；而通过 http://（比如 localhost）访问时，响应头中的 Content-Type: text/html; charset=utf-8 优先级高于 meta 标签。
- 用开发者工具 F12 → Network → 点开 HTML 请求 → Headers → Response Headers，检查
Content-Type是否含charset=utf-8 - Nginx 配置需加：
charset utf-8;；Apache 需在 .htaccess 加：AddDefaultCharset UTF-8 - Node.js/Express 中，
res.sendFile()默认不带 charset，要手动设：res.set('Content-Type', 'text/html; charset=utf-8')
最容易被忽略的点：BOM 和 meta 位置是硬性顺序要求，不是“尽量靠前”。哪怕只多一个不可见字符，整个编码链就断了。修复时务必用命令行验证真实编码和 BOM，而不是依赖编辑器界面提示。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
