订单日志写入必须通过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 并告警）。
立即学习“PHP免费学习笔记（深入）”；
Swoole\Coroutine\WriteFile 不适合高频订单日志
虽然 Swoole 提供了 Swoole\Coroutine\WriteFile 这个协程化写文件 API，但它本质是封装了 write 系统调用，并未解决磁盘 I/O 的随机延迟问题。在 SSD 尚可，但在机械盘或高负载机器上，单次 WriteFile 仍可能耗时数毫秒 —— 对订单链路来说不可接受。
-
WriteFile适合一次性写入配置、导出报表等低频操作 - 订单日志每单至少写 2–3 条（创建、支付回调、发货），QPS 上千时，逐条协程写仍是瓶颈
- 它不支持追加模式（
aflag），每次都要open+seek+write，开销更大
日志格式与路径要注意协程隔离和滚动安全
多个 Worker 进程共用一个日志文件没问题（Linux append 模式线程/进程安全），但要注意两点：
- 日志路径不能用
getcwd()或相对路径，必须用绝对路径（如/data/logs/order/），否则不同 Worker 工作目录可能不同 - 不要在协程里用
date('Y-m-d')做日志文件名滚动（如order_2024-06-15.log），因为多个协程同时判断+打开文件会冲突；应由后台日志协程统一管理滚动逻辑，或交给logrotate - 敏感字段（如用户手机号、金额）必须脱敏后再进日志，避免审计风险
真正难的不是“怎么写”，而是“怎么不让日志拖垮订单链路”——缓冲策略、刷盘时机、错误降级，这些细节比语法更重要。
