高并发下access_log需平衡延迟、吞吐与可靠性：buffer控制内存缓冲大小（推荐32k–64k），flush设定强制落盘时间（推荐5s），error_log须设warn/error级别，配合open_log_file_cache、ssd存储及精准关闭非关键日志等协同优化。
access_log 在高并发下不是“要不要记”的问题，而是“怎么记才不拖慢请求”的问题。核心矛盾在于：每条请求都同步写磁盘会变成 I/O 瓶颈，但全缓冲又可能丢日志。关键是在延迟、吞吐与可靠性之间找平衡点。
buffer 控制内存暂存容量
buffer= 后接大小（如 64k），表示每个 worker 进程为该日志分配的独立内存缓冲区上限。日志先写内存，等填满再批量刷盘。
- 太小（如 4k）：高频小写依然存在，聚合效果弱，I/O 压力下降有限
- 适中（32k–64k）：多数场景下能合并几十到上百条日志，单次 write() 显著减少系统调用
- 太大（如 128k+）：进程异常退出时可能丢失近一分钟数据，安全回溯风险上升
flush 设定最迟落盘时间
flush= 后接秒数（如 flush=2s），表示从上次刷盘起，最多等这么久就必须强制落盘——它不单独生效，必须和 buffer 配合使用。
- 1s–2s：适合 WAF 拦截、异常登录等需秒级响应的安全场景，宕机最多丢 1–2 秒日志
- 5s：通用推荐值，I/O 压力明显降低，断电或重启时日志丢失窗口可控
- 避免 flush=30s 或更长：低流量时日志可能“卡住”，攻击行为无法及时进入 SIEM 或告警系统
别忽略 error_log 的硬性限制
error_log 不支持 buffer 和 flush，始终同步写盘。如果它日志量暴增（比如 debug 级别开启），会直接拖慢 worker。
- 生产环境应将 error_log 级别设为 warn 或 error，而非 debug
- 关键安全事件（如规则拦截）可通过 log_by_lua* 写入 access_log，走 buffered 路径
- 需要保留完整上下文时，改用 error_log syslog: 转发至远程日志服务异步处理
配合其他配置才能稳住高并发
单靠 buffer+flush 不足以应对万级 QPS 场景，还需协同优化：
- 启用 open_log_file_cache，避免日志轮转时反复打开/关闭文件句柄
- 把日志路径挂载到 SSD 或独立磁盘分区，与业务数据分离，减少 I/O 竞争
- 对健康检查、静态资源等非敏感请求，用 location 精确关闭 access_log，从源头减量
- 禁用 log_not_found on，尤其 favicon.ico 类海量 404 请求，防止日志被噪音淹没
