html乱码主因是文件编码非utf-8无bom，其次为meta charset位置/写法错误、http响应头覆盖及表单/ajax传输未声明utf-8。
HTML文件保存时必须用UTF-8无BOM编码
乱码最常见原因不是HTML写法错，而是编辑器偷偷用了GBK或UTF-8+BOM保存文件。浏览器看到BOM或错误字节序，会直接解析失败，尤其在Windows记事本、VS Code未设默认编码时高频发生。
- 用VS Code打开HTML文件 → 右下角点击编码名称（如“UTF-8”或“GBK”）→ 选“Save with Encoding” → 选
UTF-8（注意不是UTF-8 with BOM） - Sublime Text：菜单栏
File → Save with Encoding → UTF-8 - 确认是否含BOM：用Hex Editor打开文件，开头三个字节不是
EF BB BF才算真正无BOM
必须放在最前面且不能写错
这个标签是浏览器解码的“第一指令”，位置和拼写出错等于没写。它不解决保存编码问题，但能帮浏览器在读取字节后正确映射为中文字符。
- 必须写成
<meta charset="UTF-8">，不是charset=UTF8（少短横）、不是charset='utf-8'（单引号虽可但易被误删）、更不是<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（旧写法，兼容性差且冗余） - 必须位于
内、且是中**第一个**非注释节点（前面不能有空格、换行或<title></title>等其他标签） - 如果用了构建工具（如Vite、Webpack），检查模板HTML是否被插件覆盖或注入了额外内容，导致
<meta charset>被挤到后面
HTTP响应头Content-Type优先级高于meta标签
本地双击打开HTML文件（file://协议）时，浏览器只看<meta charset>；但一旦走HTTP服务（localhost或线上），服务器返回的Content-Type: text/html; charset=xxx响应头会直接覆盖HTML里的meta设置——这时候改HTML毫无作用。
- 用浏览器开发者工具（Network → 刷新页面 → 点HTML请求 → Headers → Response Headers）确认
content-type值是否含charset=UTF-8 - Node.js + Express：需显式设置
res.set('Content-Type', 'text/html; charset=utf-8')，不能只靠res.sendFile() - Apache：在
.htaccess加AddDefaultCharset UTF-8；Nginx：在server块里加charset utf-8; - GitHub Pages、Vercel等静态托管平台默认用UTF-8，但若上传了带BOM的文件，仍会乱码——所以根源还是文件编码
特殊场景：表单提交或AJAX传中文要额外处理
页面显示正常 ≠ 数据传输正常。用户输入中文后提交，后端收到乱码，往往是因为表单编码未声明或XHR未设请求头。
- HTML表单加上
accept-charset="UTF-8"属性：<form accept-charset="UTF-8"></form>（虽然现代浏览器默认UTF-8，但显式声明更稳妥） - 用
fetch()发JSON数据时，确保body是字符串且已JSON.stringify()，并手动加头：headers: {'Content-Type': 'application/json; charset=UTF-8'} - 用
XMLHttpRequest时，调用request.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=UTF-8')，否则IE/旧Chrome可能按系统默认编码发送
真正卡住人的从来不是“该写哪行代码”，而是编辑器保存时无声无息塞进来的BOM，或者HTTP服务端悄悄覆盖了charset声明。动手前先查文件十六进制头、再抓包看响应头，比反复改<meta>有用得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
