日志乱码主因是编辑器默认编码（如记事本ANSI/GBK）与ThinkPHP日志实际UTF-8编码不一致；应改用VS Code等工具手动切UTF-8无BOM查看，统一开发环境、终端、CI/CD的UTF-8设置，并确保数据源头（HTTP、DB等）编码一致。
日志文件打开是乱码？先确认编辑器默认编码和文件实际编码是否一致
Windows 记事本默认用 ANSI（通常是 GBK）打开文件，而 ThinkPHP 默认用 UTF-8 写日志，没 BOM —— 这是绝大多数“乱码”感知的根源。不是日志写错了，是编辑器猜错了。
- 用 VS Code、Notepad++ 或 Sublime 打开
runtime/log/202405/xxx.log，手动切换编码为 UTF-8（无 BOM），看是否恢复正常 - 别依赖记事本判断“是否乱码”，它几乎总是错的
- 如果用
tail -f或cat在终端查看正常，那 100% 是本地编辑器编码问题
想让日志文件带 BOM 或强制 GBK？ThinkPHP 6 不支持，别白折腾
ThinkPHP 日志驱动（think\log\driver\File）底层用的是 PHP 原生 fopen + fwrite，写入时不做任何编码转换，只按 PHP 字符串当前字节流原样写入。你传进去的是 UTF-8 字符串，它就写 UTF-8 字节。
-
default_format、file_name等配置项里没有编码参数，也不存在encoding配置项 - 试图在
config/log.php里加'encoding' => 'GBK'会被直接忽略 - 改源码强行 iconv 转码？会导致中文路径、变量名、SQL 日志里的关键字被破坏，得不偿失
真正可控的环节：统一开发环境的默认编码行为
与其改日志，不如让所有环节默认按 UTF-8 处理——这才是一劳永逸的做法。
- IDE（如 PHPStorm）设置：File → Settings → Editor → File Encodings → Global Encoding / Project Encoding → 设为
UTF-8 - Windows 终端（CMD/PowerShell）：执行
chcp 65001切换到 UTF-8 模式（可加到启动脚本） - Linux/macOS 用户基本无此问题，但检查
locale输出中LANG是否含UTF-8 - CI/CD 构建机也要同步设置，否则日志上传后在 Windows 上查看又变乱码
日志内容本身出现乱码？检查源头字符串是否已损坏
如果用 file_get_contents 读取数据库字段或 HTTP 请求体后再写进日志，而该内容本身是 GBK 编码且未转 UTF-8，那日志里就会真乱码——这不是日志组件的问题，是数据流混了编码。
立即学习“PHP免费学习笔记（深入）”；
- 查
$_POST、file_get_contents('php://input')、pdo::fetch()返回值的原始字节，用mb_detect_encoding($str, ['UTF-8', 'GBK'], true)辅助判断 - Web 入口确保
<meta charset="UTF-8">和Content-Type: text/html; charset=utf-8一致 - 数据库连接必须显式指定
charset=utf8mb4，PDO DSN 中加;charset=utf8mb4，不要依赖 MySQL 服务端默认值
