Nginx多worker写同一日志文件不交织，根本原因是Linux内核保证≤4096字节的write()调用原子性，使整行日志“全有或全无”；超长日志（如含未截断大字段）会突破该边界导致交织，需通过变量截断、缓冲合并或per-worker日志规避。
nginx 多 worker 进程写同一日志文件时，不会出现日志行交织（interleaving），根本原因不是靠锁或进程协调，而是依赖操作系统内核对 write() 系统调用的原子性保障——但该保障有明确前提：单次写入长度 ≤ 4096 字节（即 PIPE_BUF 大小），且目标为普通文件（非块设备或特殊文件系统）。
为什么小日志行不会交织？
nginx 的 access_log 和 error_log 默认每条记录是一次 write() 调用完成的。只要单条日志内容（含换行符、时间戳、状态码等）总长不超过 4096 字节，Linux 内核会保证该次 write 是原子的：多个进程同时 write 到同一个文件描述符，内核会串行化这些调用，确保整行日志完整落盘，不会被其他 worker 的日志片段切开。
这意味着：
- 每条日志行是“全有或全无”的，不会出现 A 进程的日志头 + B 进程的日志中段 + A 进程的日志尾这种错乱
- 无需 nginx 自己加锁、排队或引入专用日志进程
- 该机制由内核实现，与 nginx 版本、编译选项无关
什么情况下会突破原子性边界？
当某条日志因变量展开过长（例如带超长请求体、嵌套 JSON、未截断的 referer 或 user-agent）导致单次 write 超过 4096 字节，内核不再保证原子性。此时可能出现：
- 一行日志被多个 worker 的 write 操作交叉写入，产生半截内容
- 日志行末尾缺失换行符，后续日志粘连成一行
- logrotate 切割期间，正在写入的大日志被截断或写入旧文件
典型诱因包括：$request_body、$http_x_forwarded_for（含多层代理 IP）、$args（含超长查询参数）等未做长度限制的变量参与日志格式。
如何规避交织风险？
不依赖“侥幸不超长”，而应主动控制输出粒度和结构：
- 在
log_format中避免直接使用原始大字段；改用$request_length、$body_bytes_sent等固定长度变量替代请求体内容 - 对必须记录的长字段做截断，例如：
map $http_user_agent $ua_short { ~^(.{0,200}) $1; default "-"; }，再在 log_format 中引用$ua_short - 启用
buffer=64k flush=5s（仅限 access_log），让 nginx 在内存中暂存并合并多条日志，以更少次数、更大块 write，反而更容易维持原子性（因合并后仍 ≤4K 的概率更高），同时降低 I/O 压力 - 若需绝对隔离，可配置 per-worker 日志路径，如
access_log /var/log/nginx/access-$pid.log;，但需承担更多文件句柄与磁盘 seek 开销，且需自行处理轮转逻辑
日志切割时的协同关键点
logrotate 发送 USR1 信号给 nginx 主进程，主进程负责原子重命名当前日志文件，并通知所有 worker 打开新文件。这个过程之所以安全，是因为：
- worker 不自行判断是否轮转，只响应主进程下发的指令
- 重命名（rename()）本身是原子系统调用，不会中断已有 write
- 新日志文件由主进程统一 open 后，通过 fd 传递给各 worker，避免竞争创建
因此，即使在高并发写入中触发切割，也不会丢失日志或造成文件损坏——前提是外部工具（如 logrotate）不直接 mv/truncate 正在被写的文件。
