服务器网站中文乱码本质是字符编码链路断裂，需统一html文件utf-8无bom保存、前置声明、服务端content-type响应头强制指定charset=utf-8，并确保跨域接口响应头正确声明charset。
配置 charset 指令本身并不能直接解决“不同域名”的中文乱码问题——因为 charset 不是 HTTP 协议中的独立指令，而是通过 <meta charset>、HTTP 响应头 Content-Type、文件保存编码三者协同生效的。所谓“不同域名”导致乱码，本质是各域名下资源（HTML/CSS/JS）的编码声明与实际字节流不一致，或跨域请求中响应头缺失/错误。关键在于统一和对齐这三层编码信息。
确保 HTML 文件本身以 UTF-8（无 BOM）保存
这是所有环节的基础。若文件用 GBK 编辑后另存为 UTF-8，但未清除 BOM 或保存失败，<meta charset="UTF-8"> 就会失效。
- 用 VS Code、Sublime Text 或 Notepad++ 打开 HTML 文件，检查右下角编码显示，确认为 “UTF-8”（非 “UTF-8 with BOM”）
- 在 VS Code 中：右键状态栏编码 → “Save with Encoding” → 选 “UTF-8”
- 避免用 Windows 自带记事本编辑，它默认保存为 ANSI 或带 BOM 的 UTF-8，极易引发乱码
在 中正确声明
该标签必须出现在 内且尽可能靠前（早于 <title></title> 和任何 <script></script>），否则浏览器可能已按错误编码解析了部分 HTML。
- 写法唯一推荐：
<meta charset="UTF-8">（全小写、英文引号、无空格） - 不要写成：
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">（旧式写法，兼容性差，且易被忽略） - 禁止放在
中，此位置完全无效
服务端强制发送正确的 Content-Type 响应头
浏览器优先信任 HTTP 响应头中的 Content-Type，它比 <meta> 权重更高。若域名 A 的服务器返回 Content-Type: text/html; charset=gbk，哪怕 HTML 里写了 UTF-8，也会乱码。
- 静态托管（如 Nginx/Apache）：配置 MIME 类型，确保
.html文件响应头含charset=UTF-8 - Nginx 示例：
charset utf-8;放在 server 或 location 块中 - Node.js（Express）：
res.set('Content-Type', 'text/html; charset=utf-8'); - PHP 页面开头加：
header('Content-Type: text/html; charset=utf-8');
跨域请求（如 AJAX / Fetch）需关注响应头与解码逻辑
当页面从域名 A 加载，却向域名 B 发起接口请求时，B 的响应头若未明确指定 charset，客户端可能误判编码。
- 后端接口（域名 B）必须返回
Content-Type: application/json; charset=utf-8或text/plain; charset=utf-8 - 前端 JS 获取响应时，显式指定解码方式：
response.text().then(txt => new TextDecoder('utf-8').decode(new Uint8Array(txt))) - 使用
fetch时，避免直接读response.body；优先用response.json()或response.text()，它们会自动依据响应头处理编码
