html乱码本质是文件实际编码与声明不一致所致；需确保编辑器保存格式、标签、http响应头三者统一为utf-8且无bom。
HTML 编码本身不是问题，乱码是编码不匹配的后果；二者不是并列关系，而是“因”与“果”。
HTML 文件保存编码和 <meta charset> 必须一致
浏览器解析 HTML 时，先看文件本身的字节序列（即磁盘上怎么存的），再看 <meta charset="UTF-8"> 或 <meta http-equiv="Content-Type" content="text/html; charset=GBK"> 告诉它“该怎么解”。两者不一致，必出乱码。
- 用 VS Code、Notepad++ 或 Sublime 打开 HTML 文件，右下角会显示当前文件编码（如
UTF-8、GBK、UTF-8 with BOM）——这是真实存储格式 -
<meta charset>只是“声明”，不改变文件内容；它骗不过浏览器，只影响浏览器怎么读 - 常见错误：文件存为
GBK，但写了<meta charset="UTF-8">→ 中文全变成方块或问号 - 更隐蔽的坑：
UTF-8 with BOM和纯UTF-8在某些旧环境（如 PHP 输出、某些构建工具）中会被当不同编码处理
为什么记事本改完 HTML 就乱码？
Windows 记事本默认用系统区域设置编码保存文件。中文 Windows 默认是 ANSI（实际就是 GBK），不是 UTF-8。你手动加了 <meta charset="UTF-8">，但文件仍以 GBK 存，等于告诉浏览器“请用 UTF-8 解这串 GBK 字节”——自然错乱。
- 解决方法：在记事本「另存为」时，手动选「UTF-8」编码（注意不是「UTF-8-BOM」，除非明确需要）
- VS Code 默认保存为
UTF-8，但如果你之前用记事本打开过并保存过，它可能沿用原编码，需点击右下角编码名 → 「Save with Encoding」→ 选UTF-8 - 别信记事本里“另存为 UTF-8”后就万事大吉——它有时偷偷加 BOM，而 BOM 在 HTML 开头会导致空白行或 JS 报错
服务器响应头比 <meta> 更优先
如果服务器通过 HTTP 响应头返回了 Content-Type: text/html; charset=GBK，那浏览器直接忽略 <meta charset>，哪怕你写的是 UTF-8。
- 本地双击打开 HTML 文件（
file://协议）时，没有响应头，才完全依赖<meta> - 用
python -m http.server或 Nginx 启服务时，务必确认响应头中的charset与文件编码一致 - Chrome 开发者工具 → Network → 点开 HTML 请求 → Headers → Response Headers → 查看
content-type - PHP 输出前若调用了
header('Content-Type: text/html; charset=GBK');，<meta>就失效
最易被忽略的一点：**HTML 文件开头不能有任何不可见字符**。BOM、空格、换行出现在 之前，会导致部分浏览器（尤其旧版 IE）降级使用兼容模式，连带让 <code><meta charset> 失效——这时乱码不是编码问题，是解析模式崩了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
