浏览器优先采用HTTP响应头Content-Type中的charset，而非<meta charset>；若响应头为charset=gbk或iso-8859-1，即使<meta>写对也会乱码；Nginx需配charset utf-8;，Express需res.set()前置，PHP需防BOM和前置输出。
为什么改了还是乱码？
因为浏览器优先信任 HTTP 响应头里的 Content-Type，而不是 HTML 里的 <meta charset="UTF-8">。如果服务器返回的是 Content-Type: text/html; charset=iso-8859-1 或 charset=gbk，哪怕 <meta> 写得再标准，浏览器也会强制用那个编码解析——中文直接变“且或方框。
Nginx 怎么加 UTF-8 响应头？
在 nginx.conf 的 http、server 或 location 块里加这行：
charset utf-8;
注意三点：
- 不是
charset=UTF-8（等号和大小写都不对） - 不能写成
add_header Content-Type "text/html; charset=utf-8"—— 这会覆盖 Nginx 自动加的Content-Type，导致 MIME 类型丢失，可能变成text/plain - 如果用了
try_files或静态文件服务，确保该配置生效范围覆盖到你的 HTML 文件路径
Express/Node.js 中 res.sendFile() 怎么指定 charset？
res.sendFile() 默认不带 charset，它依赖底层 send 库的默认行为（通常是 iso-8859-1）。必须显式设置：
立即学习“前端免费学习笔记（深入）”；
res.sendFile(path.join(__dirname, 'index.html'), {
headers: {
'Content-Type': 'text/html; charset=utf-8'
}
});
或者更稳妥地分两步：
res.set('Content-Type', 'text/html; charset=utf-8');
res.sendFile(path.join(__dirname, 'index.html'));
关键点：
- 必须在
res.sendFile()调用前执行res.set()，否则无效 - 不要只写
res.setHeader('Content-Type', 'text/html')—— 缺少charset=utf-8仍会 fallback - 如果路由用了中间件（如 compression），确保
res.set()在它之后调用，避免被覆盖
PHP header() 失效的常见原因
header('Content-Type: text/html; charset=utf-8'); 很容易失效，最常踩的坑是：
- PHP 文件开头有 BOM（
EF BB BF）——header()会因输出已开始而报Cannot modify header information - PHP 文件顶部有空格、换行或注释（哪怕只是
<?php前多一个空行） - 使用了
echo、print或 HTML 内容在header()之前输出 - Apache 的
AddDefaultCharset配置强行覆盖了 PHP 的 header
验证是否生效：F12 → Network → 刷新 → 点 HTML 请求 → 查看 Response Headers 里的 Content-Type。如果还是 text/html 没带 charset，说明 header 没发出去，先查 BOM 和前置输出。
