swoole 没有 pipe_buffer_size 配置项，它不存在于任何稳定版文档或源码中；实际应使用 socket_buffer_size 控制 tcp 连接收发缓冲，buffer_output_size 控制单次 send 最大长度。
没有 pipe_buffer_size 这个 Swoole 配置项，它根本不存在于任何稳定版 Swoole 的文档或源码中。
你看到的可能是混淆了几个概念：一是 Linux 内核的管道（pipe）系统调用缓冲区（默认 64KB，由 /proc/sys/fs/pipe_buf 控制），二是 Swoole 自己内部进程间通信用的 swPipe 结构，三是被误传或拼错的 socket_buffer_size 或 buffer_output_size。
为什么搜不到 pipe_buffer_size？
Swoole 源码里没有定义、没有读取、也没有任何地方校验这个配置键。所有官方文档（看云、GitHub Wiki、PHP 手册）、所有发行版本（包括 4.8.x 到 5.1.x）均未收录该参数。尝试在 $server->set() 中传入 'pipe_buffer_size' => 65536 不会产生任何效果，也不会报错——它只是被静默忽略。
- 真正控制 TCP 连接收发缓冲的是
socket_buffer_size（影响每个连接的读写缓存大小） - 真正控制单次 send() 最大长度的是
buffer_output_size（注意不是“pipe”） - Swoole 内部进程通信用的匿名管道（
swPipeBase）是固定大小创建的，不暴露给用户配置
你实际想调的可能是 socket_buffer_size
如果你在压测中遇到 swFactoryProcess_finish: send failed, session#1 output buffer has been overflowed，或者发现高并发下内存暴涨、小包延迟高，那真正该检查和调整的是 socket_buffer_size：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 它决定每个 TCP 连接的「发送缓冲区」上限（单位字节），不是内核 pipe 缓冲
- 设太大（比如 128MB）→ 万级连接时直接吃光几 GB 内存
- 设太小（比如 4KB）→ 小数据高频场景下频繁触发
write()系统调用，CPU 上升 - 必须同步检查系统限制：
cat /proc/sys/net/core/wmem_max，Swoole 值不能超过它
示例正确写法：
$server->set(['socket_buffer_size' => 262144]); // 256KB
别被“pipe”这个词带偏：Swoole 的管道不归你管
Swoole 进程间通信（如 worker ↔ manager、task worker ↔ worker）确实用了 pipe() 系统调用创建的匿名管道，但这些管道的缓冲行为完全由内核管理，且 Swoole 在创建后就设为非阻塞模式，并通过 epoll 监听，不会堆积大量数据。你无法、也不应试图去调它的“buffer size”：
-
swPipeBase结构体里只有两个 fd（pipes[0]和pipes[1]），没有 buffer 大小字段 - 源码中创建管道只调
pipe()+swSetNonBlock()，无额外 setsockopt - 所谓“管道溢出”错误，在 Swoole 日志里从来不会出现——它只会出现在 socket 发送失败时
真正容易被忽略的点是：当你在协程里用 file_get_contents() 或 sleep() 却没启用 SWOOLE_HOOK_ALL，会导致整个 worker 进程卡住，看起来像“管道堵了”，其实跟 pipe 一点关系都没有。
