乱码主因是HTTP响应头缺失charset声明。浏览器只认Content-Type中的charset，不猜测编码；需后端显式设置如text/html; charset=utf-8，<meta charset>仅为备选且须位于<head>最前；文件实际编码须与声明一致，并确保数据库、Ajax等全链路UTF-8统一。
页面显示乱码，先看 Content-Type 响应头有没有 charset
浏览器不猜编码，它只认响应头里的 Content-Type。如果后端返回的是 text/html 但没带 charset=utf-8，哪怕文件本身是 UTF-8，Chrome 也可能按 ISO-8859-1 解析，中文直接变 。
- 用浏览器开发者工具（Network → Header）检查响应头，确认
Content-Type值类似text/html; charset=utf-8 - PHP 中用
header('Content-Type: text/html; charset=utf-8');显式设置，别依赖default_charset配置 - Node.js 的 Express 默认不设 charset，需手动加：
res.set('Content-Type', 'text/html; charset=utf-8'); - 静态 HTML 文件如果靠服务器直发，得靠 Web 服务器配置——Nginx 要加
charset utf-8;，Apache 要确保AddDefaultCharset UTF-8生效
<meta charset> 是备选方案，不是兜底方案
<meta charset="utf-8"> 只在浏览器没从 HTTP 响应头拿到编码时才起作用，而且必须出现在 <head> 最前面（最好第一行），否则前面的字节已按错误编码解析了，再改也晚了。
- 不要写成
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">—— 这是旧写法，现代浏览器优先忽略它 - 如果 HTML 文件开头有 BOM（比如 UTF-8-BOM），
<meta charset>可能被跳过或失效，建议用编辑器保存为 “UTF-8 无 BOM” - 服务端渲染模板（如 EJS、Jinja）里，
<meta charset>写对了也没用——关键还是响应头
文件实际编码和声明不一致，乱码就稳了
编辑器显示正常 ≠ 文件编码正确。常见陷阱是：用记事本存成 ANSI（其实是 GBK），却在 HTML 里写 <meta charset="utf-8">，或者用 VS Code 存成 UTF-8，但后端又用 GBK 读取再输出，中间转码崩了。
- 用命令行查真实编码：
file -i filename.html（Linux/macOS）或chcp+ 看编辑器状态栏（Windows） - Python 读写文件时务必显式指定
encoding='utf-8'，别依赖open()默认行为（它随系统 locale 变） - 数据库字段存中文？确认表字符集是
utf8mb4，连接时也要带charset=utf8mb4参数，MySQL 的utf8实际只支持 3 字节 UTF-8，emoji 和部分生僻字会截断
Ajax 加载 HTML 片段时，responseText 编码容易被忽略
用 XMLHttpRequest 或 fetch() 拿 HTML 字符串时，如果接口没返回正确的 Content-Type 头，responseText 可能是乱码，即使页面主文档编码完全正确。
立即学习“前端免费学习笔记（深入）”；
-
fetch()默认按响应头解析编码，但如果后端返回text/plain，它不会主动查<meta>，结果就是原始字节流被当成 Latin-1 解码 - 稳妥做法：后端统一返回
text/html; charset=utf-8；前端若无法控制后端，可用response.arrayBuffer()手动按 UTF-8 解码（配合TextDecoder） - jQuery 的
$.get()在老版本中对编码处理更模糊，建议升级或换原生方案
charset 参数。 
