nginx所有worker进程共用同一日志文件描述符，并发写入依赖内核write原子性；非独立通道。需用$pid或$worker_pid变量显式配置不同路径才能实现per-worker日志，但会增加文件句柄与i/o开销。

Nginx 本身并不为每个 worker 进程单独开辟独立的日志写入通道。它的日志写入机制是**所有 worker 进程共用同一个打开的文件描述符（fd）**，通过操作系统内核的 write() 系统调用并发写入同一日志文件——这本质上是共享通道，而非独立通道。

为什么不是“独立日志通道”？

当 Nginx 启动时，master 进程在 fork 所有 worker 前，会预先打开 access_log 和 error_log 对应的文件（或 syslog socket），并将这些 fd 传递给各 worker 进程。因此所有 worker 实际写入的是同一个 fd，依赖内核保证 write() 的原子性（对小块数据）和文件偏移同步。这不是进程隔离的日志通道，而是多进程竞争同一输出端点。

真正的“独立”需手动实现

若确实需要每个 worker 写入不同日志文件（例如调试定位、性能隔离或避免锁争用），必须显式配置差异化日志路径，常见方式包括：

• 使用 $pid 变量： access_log /var/log/nginx/access-$pid.log; —— 每个 worker 启动时 pid 不同，自动创建独立文件
• 使用 $worker_pid（需 nginx ≥ 1.19.2）：更语义明确，效果同上
• 配合 logrotate 或自定义脚本，按 worker 分组归档，但需注意文件句柄生命周期管理

注意事项与风险

启用 per-worker 日志会显著增加文件句柄占用和磁盘 I/O 分散度，可能引发：

• 大量小文件堆积，影响 inode 使用和清理效率
• logrotate 配置需适配通配符（如 /var/log/nginx/access-*.log），否则遗漏轮转
• 无法直接使用 tail -f 统一观察所有请求流，排查需合并或多窗口跟踪
• error_log 不建议 per-worker，因错误上下文常需全局关联分析

替代方案：更实用的日志分离策略

相比强行拆分 worker 日志，以下方式更常用且稳健：

• 按 server 或 location 分别配置 access_log，实现业务维度隔离
• 用 log_format 定制字段（如加入 $msec、$request_id、$upstream_addr），便于后端集中采集与关联追踪
• 将日志输出到 systemd-journald 或 fluentd 等中间层，由其做聚合、过滤与分发
• 在高并发场景下，启用 buffer 和 flush 参数（如 access_log ... buffer=64k flush=5s;）缓解 write 频次压力