17370845950

订单日志写入必须通过Channel+后台协程实现非阻塞投递，禁用fopen/file_put_contents等同步I/O；需控制缓冲大小、统一滚动管理、敏感字段脱敏，并避免Swoole WriteFile用于高频场景。

订单日志写入必须避开 fopen / file_put_contents 同步阻塞

在 Swoole 协程环境下直接用 fopen 或 file_put_contents 写日志，会导致当前协程挂起（底层仍是同步 I/O），严重拖慢订单处理吞吐。协程的并发优势会因此归零。

正确做法是：把日志写入委托给独立的协程或通道，主协程只负责投递日志内容。

• 不要在 onReceive、onRequest 或订单核心逻辑里直接调用文件写函数
• 用 Swoole\Coroutine\Channel 缓冲日志消息，由后台协程消费并批量刷盘
• 若需落库，也必须用 Swoole\Coroutine\MySQL，禁用 PDO 或 mysqli 同步驱动

用 Channel + 后台协程实现非阻塞日志投递

这是最轻量、可控性最强的方案，适合订单日志这种高频率但格式固定的场景。关键点在于控制缓冲大小和刷盘时机，避免内存积压。

use Swoole\Coroutine\Channel;
use Swoole\Coroutine;

$loggerChannel = new Channel(1024);

// 启动后台日志协程（通常在 Server 启动后立即 go()）
Coroutine::create(function () use ($loggerChannel) {
    $fp = fopen('/tmp/order.log', 'a');
    if (!$fp) {
        throw new RuntimeException('Failed to open order.log');
    }
    stream_set_write_buffer($fp, 0); // 关闭系统缓冲，确保 write 立即生效

    while (true) {
        $msg = $loggerChannel->pop();
        if ($msg === false) {
            continue;
        }
        fwrite($fp, date('Y-m-d H:i:s') . " [ORDER] {$msg}\n");
        fflush($fp); // 强制刷盘，避免进程退出时丢失
    }
});

// 订单处理中投递日志（完全不阻塞）
function logOrder($orderNo, $status, $data = []) {
    global $loggerChannel;
    $loggerChannel->push("order_no={$orderNo},status={$status}," . http_build_query($data));
}

注意：Channel 容量设为 1024 是经验值，过高会吃内存，过低易丢日志（push 会阻塞或失败）。生产环境建议加超时和降级逻辑（如满时写入 /dev/null 并告警）。

Swoole\Coroutine\WriteFile 不适合高频订单日志

虽然 Swoole 提供了 Swoole\Coroutine\WriteFile 这个协程化写文件 API，但它本质是封装了 write 系统调用，并未解决磁盘 I/O 的随机延迟问题。在 SSD 尚可，但在机械盘或高负载机器上，单次 WriteFile 仍可能耗时数毫秒 —— 对订单链路来说不可接受。

• WriteFile 适合一次性写入配置、导出报表等低频操作
• 订单日志每单至少写 2–3 条（创建、支付回调、发货），QPS 上千时，逐条协程写仍是瓶颈
• 它不支持追加模式（a flag），每次都要 open + seek + write，开销更大

日志格式与路径要注意协程隔离和滚动安全

多个 Worker 进程共用一个日志文件没问题（Linux append 模式线程/进程安全），但要注意两点：

• 日志路径不能用 getcwd() 或相对路径，必须用绝对路径（如 /data/logs/order/），否则不同 Worker 工作目录可能不同
• 不要在协程里用 date('Y-m-d') 做日志文件名滚动（如 order_2025-06-15.log），因为多个协程同时判断+打开文件会冲突；应由后台日志协程统一管理滚动逻辑，或交给 logrotate
• 敏感字段（如用户手机号、金额）必须脱敏后再进日志，避免审计风险

真正难的不是“怎么写”，而是“怎么不让日志拖垮订单链路”——缓冲策略、刷盘时机、错误降级，这些细节比语法更重要。