php在windows下处理中文日志路径乱码，需统一编码：脚本保存为utf-8无bom，路径用mb_convert_encoding转gbk；读取时用mb_detect_encoding探测并转utf-8；避免glob()改用scandir()；写入前设mb_internal_encoding(‘utf-8’)并校验编码。
PHP 删除日志文件时中文路径乱码
Windows 系统下用 unlink() 或 file_exists() 处理含中文的 log 路径，常返回 false 或报错「No such file or directory」，本质是 PHP 默认使用 ANSI（如 GBK）编码解析文件系统路径，而脚本源码或终端可能是 UTF-8。
- 确认当前脚本保存编码：用编辑器查是否为 UTF-8 无 BOM；若为 GBK，
unlink('日志_2024.log')可能成功，但换到 Linux 就失效 - 统一转为系统本地编码再操作：Windows 下用
mb_convert_encoding($path, 'GBK', 'UTF-8')，Linux/macOS 通常无需转换（默认 UTF-8 文件系统） - 更稳妥的做法是避免中文路径：日志命名用时间戳+哈希，如
log_20240520_8a3f.log，彻底绕过编码争议
file_get_contents() 读取日志时出现乱码或截断
日志文件本身可能是 GBK、BIG5 或 UTF-8-BOM 编码，而 file_get_contents() 不做自动编码识别，直接按字节读取，后续用 strlen() 或正则匹配就容易出错。
- 先用
mb_detect_encoding(file_get_contents($log), ['UTF-8', 'GBK', 'BIG5'], true)探测（注意第三个参数设为true启用 strict 模式） - 探测不准时，优先检查文件 BOM：
hexdump -C $log | head -1，EF BB BF 是 UTF-8-BOM，反之可能是无 BOM 的 UTF-8 或其他编码 - 统一转成 UTF-8 再处理：
$content = mb_convert_encoding($raw, 'UTF-8', $detected)，之后所有字符串操作才可靠
用 glob() 匹配日志文件名时漏掉带中文的文件
glob('logs/*.log') 在 Windows 上默认不支持 UTF-8 路径通配，即使目录里有 错误_记录.log，也返回空数组。
