HTML乱码本质是浏览器用错编码解码字节流，需同步确保文件保存编码、<meta charset>声明与HTTP响应头三者一致为UTF-8（或实际编码），缺一不可。
HTML 乱码本质是浏览器用错了编码去解码字节流，不是文件“坏了”，改对 <meta charset> 或服务器响应头就大概率恢复正常。
浏览器没读到正确的 charset 声明
最常见原因：HTML 文件里缺 <meta charset="UTF-8">，或它写在了 <title> 后面、甚至 <body> 里——浏览器只认 <head> 开头附近、且越靠前越可靠。
- 确保
<meta charset="UTF-8">是<head>中第一个标签（紧贴<head>开始） - 别写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，旧写法兼容性差，且容易被忽略 - 如果文件实际保存为 GBK，但写了
UTF-8，反而会更乱——编码声明必须和文件真实编码一致
文件本身保存编码和声明不匹配
编辑器保存时选错编码，比如用 VS Code 默认 UTF-8 保存了含中文的文件，但手动改过声明为 GBK，浏览器按 GBK 解 UTF-8 字节，必然乱码。
- 用编辑器（如 VS Code、Notepad++）检查右下角显示的当前文件编码，确认是
UTF-8还是GBK - 如果内容是简体中文且无特殊历史要求，统一用
UTF-8 without BOM保存（BOM 可能引发 PHP 等后端问题） - 改完保存编码后，务必同步更新
<meta charset>值，两者必须严格一致
服务器返回的 HTTP 响应头覆盖了 HTML 声明
即使 <meta charset="UTF-8"> 写对了，如果服务器通过 Content-Type: text/html; charset=GBK 响应头强制指定编码，浏览器优先信响应头。
立即学习“前端免费学习笔记（深入）”；
- 用浏览器开发者工具（Network → Headers）查看响应头里的
Content-Type字段 - Apache 用户检查
.htaccess或主配置是否有AddDefaultCharset GBK类指令 - Nginx 用户检查是否有
charset GBK;，应改为charset utf-8;（注意 nginx 里是utf-8，不是UTF-8） - PHP 输出前调用了
header('Content-Type: text/html; charset=GBK');？删掉或改成utf-8
动态内容（JS / AJAX）加载后出现局部乱码
页面主体正常，但 JS 用 fetch 或 XMLHttpRequest 加载的 HTML 片段或 JSON 数据显示乱码，问题常出在请求未声明编码或服务端返回头缺失。
-
fetch默认按 UTF-8 解析响应体，但如果接口返回的是 GBK 编码的文本，必须手动处理：response.arrayBuffer()+TextDecoder('gbk') - 后端接口（如 PHP/Python）输出 JSON 时，确保加了
Content-Type: application/json; charset=utf-8响应头 - 避免用
innerHTML直接插入未解码的响应文本；若响应是纯文本且编码不确定，先用TextDecoder显式解码再赋值
真正麻烦的不是改哪一行，而是要同时盯住三处：文件保存编码、<meta charset> 声明、HTTP 响应头。少对一环，乱码就还在那儿，而且表现还可能不一致——比如本地双击打开正常，一丢到服务器就乱。
