Workerman多进程写日志不乱依赖Linux内核write原子性（≤4096字节且O_APPEND打开），超长日志会交织；file_put_contents不安全；推荐用专用日志进程串行写入。
Workerman多进程写日志不乱，靠的是内核级write原子性，但仅限≤4096字节
Workerman本身不加锁、不排队，多个Worker进程能安全往同一文件追加日志，根本原因不是PHP或Workerman做了什么，而是Linux内核对write()系统调用的保障：当单次写入长度 ≤ 4096 字节（即PIPE_BUF），且文件以O_APPEND方式打开（PHP的'a'模式底层即如此），内核会串行化所有进程的write()调用，确保整条日志“全有或全无”。
这解释了为什么默认Worker::log()写短消息时看起来没问题——它通常只写一行带时间戳的文本，远小于4KB。但一旦日志内容膨胀（比如var_dump($hugeArray)、未截断的$connection->getRemoteIp()或超长JSON），就可能突破边界，触发交织。
file_put_contents(..., FILE_APPEND)在Workerman里其实很危险
很多人直接用file_put_contents('runtime/log/workerman.log', $msg, FILE_APPEND)，以为它“自动追加”就安全。实际上它底层仍是fopen(..., 'a') + fwrite()，而'a'模式只保证lseek()到文件末尾的动作是原子的，不保证后续write()内容不被其他进程切开——尤其当$msg超长或系统缓冲区满时。
- 常见错误现象：
tail -f看到半截JSON、两行日志挤成一行、换行符丢失导致后续日志粘连 - 性能影响：频繁
file_put_contents()会反复打开/关闭文件句柄，比复用fopen句柄慢数倍 - 权限陷阱：若日志目录由root创建但Worker以
www-data运行，第一次写入可能静默失败（无报错，文件为空）
真正可靠的方案是把写文件这件事移出Worker进程
Workerman官方推荐、也是生产环境最稳的做法：Worker进程不碰磁盘IO，只通过Unix Socket或TCP把日志消息发给一个专用的日志进程（比如用Swoole\Process或独立php log_server.php启动），由它串行写入。
- Worker端发送示例：
$fp = stream_socket_client('unix:///tmp/log.sock', $errno, $errstr, 0.1); fwrite($fp, json_encode(['level'=>'info', 'msg'=>$data])."\n"); fclose($fp); - 必须设超时（如
0.1秒），否则日志进程卡住会拖垮整个服务 - 降级策略不能少：若
stream_socket_client()失败，应暂存内存队列或写入临时文件，避免丢日志 - 不要用
flock()硬扛——它需要所有进程共用同一锁文件路径，且加锁/解锁失败时难诊断，一漏就全崩
调试时别信echo和var_dump，但log文件也可能看不到输出
Workerman常驻进程会把stdout重定向到/dev/null，所以echo和var_dump必然没反应；而Worker::log()若没显式设置Worker::$logFile，默认走error_log()，可能被系统syslog吞掉或缓冲延迟。
最容易被忽略的一点：日志路径的父目录权限必须允许Worker用户写入，且不能依赖相对路径（如'logs/workerman.log'）。建议始终用绝对路径，并在启动前用touch /tmp/test.log && chown www-data:www-data /tmp/test.log验证权限链是否畅通。
