PHP中文乱码主因是编码不一致：文件保存、HTTP头、HTML meta、MySQL连接、日志写入需统一UTF-8；实操须确保编辑器存为UTF-8无BOM，Web页加header与meta，MySQL设utf8mb4，日志前校验并转码。
PHP文件本身没声明UTF-8编码
很多PHP脚本在开头没写header('Content-Type: text/html; charset=utf-8');，或没在HTML的里声明，导致浏览器按GBK/ISO解析，中文显示成方块或问号。这不是日志的问题，是输出层的编码错位。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 纯PHP脚本（非Web）不用管
header()，但确保编辑器保存为UTF-8无BOM格式 - Web页面必须在
后第一行加header('Content-Type: text/html; charset=utf-8'); - HTML中同步加
，否则部分浏览器会忽略HTTP头 - 用
mb_internal_encoding('UTF-8');统一内部编码，避免mb_*函数出错
fopen/fwrite写入日志时没指定编码
PHP本身不自动转码，fwrite()只是原样把字符串字节写进文件。如果源字符串是UTF-8，而日志文件被当成ANSI打开（比如Windows记事本默认用本地编码），就会乱码。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确认PHP源码文件是UTF-8无BOM —— 用VS Code右下角检查，别用记事本另存
- 写日志前强制转码：用
mb_convert_encoding($msg, 'UTF-8', 'auto')兜底处理来源不确定的字符串 - 日志文件开头可手动写BOM（不推荐）：
fwrite($fp, "\xEF\xBB\xBF");，但更稳妥的是用编辑器统一设为UTF-8打开 - Linux服务器上用
file -i your.log确认文件实际编码，别凭感觉判断
error_log()和file_put_contents()中文乱码
error_log()直接写系统日志（如Apache的error.log），它不走PHP输出层，也不受header()影响；file_put_contents()则完全依赖传入字符串的原始字节。两者都“只写不译”。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
-
error_log()写中文前，先用iconv('UTF-8', 'GB2312//IGNORE', $msg)转成目标环境支持的编码（仅限Windows IIS+GBK日志场景） -
file_put_contents('app.log', date('[Y-m-d H:i:s] ').$msg.PHP_EOL, FILE_APPEND | LOCK_EX);——重点是确保$msg本身就是UTF-8字节流 - 避免混用
echo调试和file_put_contents()记录：前者可能被HTML编码干扰，后者要绝对干净 - 用
mb_check_encoding($msg, 'UTF-8')做校验，false就说明源头已损坏，得查输入来源（如POST、数据库查询）
MySQL查询结果写日志出现乱码
这是最隐蔽的一环：PHP脚本是UTF-8，但MySQL连接用的是latin1，SELECT出来的字段实际是乱码字节，再怎么mb_convert_encoding也救不回来。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 连接后立刻执行
mysqli_set_charset($conn, 'utf8mb4');（注意是utf8mb4，不是utf8） - 建表时字段明确指定
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - PHP PDO需在DSN里加
;charset=utf8mb4，并设置PDO::ATTR_EMULATE_PREPARES => false - 用
SHOW VARIABLES LIKE 'character%';确认MySQL服务端、连接、客户端三处编码是否全为utf8mb4
iconv，先用bin2hex()打个日志看前几个字节是不是efbbbf（BOM）或e4b8ad（“中”的UTF-8），比猜快得多。 
