html文件必须保存为utf-8无bom编码；须置于内最前；服务器响应头content-type优先级最高；ajax中文乱码需后端设charset或js显式指定mime类型。
html 文件保存时用什么编码？
必须存为 UTF-8（无 BOM）。不是 UTF-8 with BOM，也不是 GBK 或 ISO-8859-1。BOM 会导致某些旧版 IE 或 Node.js 环境下解析出错，比如 <script></script> 标签前多出不可见字符，引发语法错误。
编辑器里确认方式：
– VS Code：右下角点击编码名 → 选 “Save with Encoding” → 选 UTF-8
– Sublime Text：File → Save with Encoding → UTF-8
– 记事本：另存为 → 编码下拉框必须选 UTF-8（不是“UTF-8-BOM”）
放哪儿才生效？
必须放在 内、且越靠前越好，最好紧贴 开始标签。浏览器一旦开始解析内容就可能触发渲染，如果 <meta charset="utf-8"> 写在 <title></title> 后面或中间夹了 JS，前面已读的字节可能已被按默认编码（如 Windows-1252）解码，乱码已发生，再改也晚了。
正确写法示例：
<head> <meta charset="utf-8"> <title>页面标题</title> <meta name="viewport" content="width=device-width"> </head>
常见错误：
立即学习“前端免费学习笔记（深入）”；
- 把
<meta charset>放在里（完全无效） - 写成
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">（过时写法，兼容性差，部分环境不识别） - 漏掉引号，写成
<meta charset="utf-8">（HTML5 允许，但易被误读，建议加双引号）
服务器响应头 Content-Type 优先级更高
如果服务器返回 HTTP 响应头里带了 Content-Type: text/html; charset=gbk，哪怕 HTML 里写了 <meta charset="utf-8">，浏览器也会以响应头为准——这是规范行为，不是 bug。
检查方式：
- Chrome DevTools → Network → 刷页面 → 点 HTML 请求 → Headers → Response Headers → 找
content-type - 命令行：
curl -I https://yoursite.com/index.html
修复路径：
- Apache：配置
AddDefaultCharset UTF-8或在.htaccess加Header set Content-Type "text/html; charset=utf-8" - Nginx：在 server 块中加
charset utf-8; - Node.js（Express）：
res.set('Content-Type', 'text/html; charset=utf-8')
JS 动态插入 HTML 时中文变乱码？
不是 HTML 编码问题，是 JS 字符串本身被错误解码了。典型场景：AJAX 返回文本含中文，但响应头没设 charset，或 JS 用 responseText 读取时浏览器按错误编码解析。
安全做法：
- 后端接口统一返回
Content-Type: application/json; charset=utf-8，前端用JSON.parse()解析（JSON 标准强制 UTF-8） - 若必须用
XMLHttpRequest读 HTML 片段，显式设置xhr.overrideMimeType('text/html; charset=utf-8') - 避免用
document.write()插入含中文的字符串（已废弃，且编码不可控）
一个容易忽略的点：Webpack/Vite 构建时，如果 HTML 模板文件本身是 GBK 编码，而构建工具默认按 UTF-8 读取，就会直接把乱码塞进最终 HTML —— 构建前务必确认源文件编码。
