PHP乱码根源在文件编码、HTTP头、CLI环境、MySQL连接、HTTP响应五层未统一：需保存UTF-8无BOM、加header、设locale、PDO显式set charset、按响应头转码。
PHP脚本文件本身没声明UTF-8编码
很多乱码问题根源不在输出环节，而在PHP源文件保存格式和头部声明缺失。如果编辑器用GBK保存.php文件，又没加header()或BOM，浏览器或终端读取时就会按默认编码解析，导致中文注释、字符串字面量显示为乱码。
- 用VS Code、PhpStorm等编辑器检查右下角编码显示，强制保存为
UTF-8 without BOM - 在PHP文件顶部（任何输出之前）加上：
header('Content-Type: text/html; charset=utf-8'); - CLI环境不走HTTP头，此时需确保终端支持UTF-8（Linux/macOS一般默认支持；Windows CMD需执行
chcp 65001），且脚本中避免隐式输出（如文件末尾空行、BOM）
cron定时任务里echo中文变问号或方块
crontab默认使用C locale，不支持UTF-8，即使PHP文件是UTF-8、也加了header()，cron执行时仍会把中文转成?或空格。这不是PHP错，是系统环境没配对。
- 在crontab条目里显式设置locale：
* * * * * LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 /usr/bin/php /path/to/script.php
- 或者在PHP脚本开头调用：
putenv('LANG=en_US.UTF-8'); setlocale(LC_ALL, 'en_US.UTF-8');（注意：某些共享主机禁用putenv） - 避免用
echo直接输出带中文的日志，改用file_put_contents($log, date('Y-m-d H:i:s') . " 处理完成\n", FILE_APPEND | LOCK_EX);，日志文件用UTF-8打开即可
MySQL查询结果中的中文在定时任务里变乱码
PHP连MySQL时，连接层、数据库层、表字段层的编码不一致，会导致SELECT出来的中文在CLI定时任务中显示异常——即使网页访问正常。
- 确认MySQL服务端编码：
SHOW VARIABLES LIKE 'character_set%';，重点看character_set_server应为utf8mb4 - PHP连接时必须显式设置字符集：
$pdo = new PDO($dsn, $user, $pass, [PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"]);
或mysqli中调用$mysqli->set_charset('utf8mb4') - 不要依赖
my.cnf里的default-character-set，CLI模式下MySQL客户端可能不加载该配置
file_get_contents()或curl获取网页含中文，写入文件后乱码
这类操作常见于抓取页面生成静态HTML或日志，容易忽略HTTP响应头里的charset，直接存盘导致编码错位。
立即学习“PHP免费学习笔记（深入）”；
- 先检查远程响应头：
$headers = get_headers($url, 1); var_dump($headers['Content-Type'] ?? ''); // 可能含 charset=utf-8
- 若返回的是
text/html; charset=gbk，就不能直接file_put_contents，得先转码：$content = iconv('GBK', 'UTF-8//IGNORE', $content); - 写入文件前统一用
mb_convert_encoding($content, 'UTF-8', 'auto')兜底，比单纯iconv容错更强
实际跑定时任务时，乱码往往不是单点问题，而是文件编码、PHP运行环境、MySQL连接、HTTP响应四层叠加的结果。每层都得单独验证，不能只改PHP代码就以为解决了。
