PHP mail()乱码根源是邮件头缺失MIME声明和字符集标注，必须手动设置Content-Type与Content-Transfer-Encoding头，并对正文base64编码；mb_send_mail()可简化处理但需正确传入UTF-8编码参数。
PHP mail() 函数发邮件正文乱码的根源
根本原因不是“没加编码”，而是邮件头缺失必要的 MIME 声明和字符集标注。PHP 的 mail() 是个裸接口，不自动设置 Content-Type 或 Content-Transfer-Encoding，默认按 ASCII 处理，中文直接被截断或显示为问号、方块。
必须手动设置的两个关键邮件头
只改正文 mb_convert_encoding() 或加 header('Content-Type: text/html; charset=utf-8') 没用——那是给浏览器看的，不是给邮件客户端看的。真正起作用的是以下两个头字段：
-
Content-Type: text/plain; charset=UTF-8（纯文本）或text/html; charset=UTF-8（HTML 邮件） -
Content-Transfer-Encoding: base64（推荐）或quoted-printable
示例完整头信息：
$headers = "From: sender@example.com\r\n";
$headers .= "MIME-Version: 1.0\r\n";
$headers .= "Content-Type: text/html; charset=UTF-8\r\n";
$headers .= "Content-Transfer-Encoding: base64\r\n";
$body = base64_encode("你好，世界
"); // 正文必须 base64 编码
mail("to@example.com", "测试邮件", $body, $headers);
用 mb_send_mail() 替代 mail() 更省事
mb_send_mail() 是 PHP 内置的多字节安全封装，会自动处理编码转换和头设置，但前提是正确传入 $encoding 参数：
立即学习“PHP免费学习笔记（深入）”；
- 第三个参数（正文）保持原始 UTF-8 字符串，不要提前
base64_encode() - 第四个参数（头）仍需包含
Content-Type，否则它不会自动加 - 第五个参数（
$encoding）必须显式写"UTF-8"，不能省略或写错大小写
正确调用：
$headers = "From: sender@example.com\r\n";
$headers .= "Content-Type: text/html; charset=UTF-8\r\n";
mb_send_mail("to@example.com", "测试", "中文正常显示
", $headers, "-f sender@example.com");
注意：mb_send_mail() 依赖 mbstring 扩展已启用，且 mb_internal_encoding() 最好也设为 "UTF-8"。
HTML 邮件里
很多开发者在 HTML 正文中加 ，这完全无效——邮件客户端不解析 HTML 的 ，只认邮件头里的 charset。更糟的是，如果邮件头声明了 charset=GBK，而正文又含 ，部分 Outlook 会直接崩溃渲染。
真正要检查的只有三点：
- 邮件头
Content-Type中的charset值是否为UTF-8（注意连字符、大小写、拼写） - 正文字符串本身是否确实是 UTF-8 编码（用
mb_check_encoding($str, 'UTF-8')验证） - 若用
base64编码，是否对原始 UTF-8 字符串编码，而非对 GBK 字符串再编码
乱码问题往往卡在第二点：数据库读出、文件读取、表单提交来的字符串，可能已是 GBK 或乱码状态，这时加头也没用。
