HTML页面中文乱码主因是meta charset声明、文件实际编码、HTTP响应头三者不一致；必须统一为UTF-8（无BOM），且<meta charset="UTF-8">须置于<head>内首个非空白非注释标签位置，因浏览器仅解析前1024字节找该声明，否则回退默认编码导致乱码。
HTML页面出现中文乱码，90%不是代码写错了，而是字符集没对上——meta charset声明、文件实际编码、HTTP响应头三者必须一致，缺一不可。
为什么放在最前面？
浏览器解析HTML时，一旦遇到非ASCII字符（比如中文、 emoji），会立刻回溯到文档开头找字符集声明。如果<meta charset="UTF-8">写在<title></title>后面，或者被注释/脚本挡住了，浏览器可能已按默认编码（通常是ISO-8859-1）开始解析，再改也晚了。
- 必须紧贴
起始标签，且是内第一个非空白、非注释的标签 - 不能写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">——这是HTML4写法，虽兼容但冗余，且容易拼错http-equiv或content值 - 别用编辑器“另存为UTF-8”就以为万事大吉：Windows记事本保存的“UTF-8”默认带BOM，而
<meta charset="UTF-8">不认BOM，会导致页面开头多出乱码字符
文件保存编码和meta声明不一致会怎样？
现象很典型：本地双击打开正常，但放到服务器上就乱码；或者F12看Network里Response Headers显示Content-Type: text/html; charset=iso-8859-1，哪怕你写了<meta charset="UTF-8">也没用——因为HTTP响应头优先级高于meta。
- 检查方式：用VS Code右下角状态栏看当前文件编码（如显示“UTF-8 with BOM”，点它→“Save with Encoding”→选“UTF-8”）
- 服务器端要同步配置：
AddDefaultCharset UTF-8（Apache）或charset utf-8;（Nginx），否则HTTP头不发charset，浏览器就按历史默认猜 - 动态页面（如JSP/PHP）还要确认服务端输出前没调用过
response.setCharacterEncoding("GBK")这类覆盖操作
charset设置只影响HTML本身，不影响AJAX或表单提交
<meta charset="UTF-8">只告诉浏览器“怎么解码这个HTML文件”，但不会自动让fetch()请求、XMLHttpRequest响应或<form enctype="application/x-www-form-urlencoded"></form>提交的数据也变成UTF-8。
立即学习“前端免费学习笔记（深入）”；
- 表单提交乱码？加
accept-charset="UTF-8"属性：<form accept-charset="UTF-8"></form> - AJAX返回JSON乱码？确保后端响应头含
Content-Type: application/json; charset=UTF-8，且JSON字符串本身是UTF-8编码 - 引入外部JS/CSS文件？它们的编码由各自
Content-Type响应头决定，跟HTML的meta charset无关
真正麻烦的从来不是写哪行代码，而是查哪一层没对齐：编辑器存的编码、meta写的声明、服务器发的响应头、甚至CDN缓存里存的老版本HTTP头——只要其中一环掉链子，中文就变方块。
