Workerman 不存在 send_buffer_roll_back 错误或回调，该字符串未出现在官方源码、文档或任何稳定版本中；实际应为 error 2 send buffer full 日志或业务代码/中间件误输出。
Workerman 没有 send_buffer_roll_back 这个错误或回调——这是误传或混淆了日志内容。你实际看到的，极大概率是 workerman error 2 send buffer full and drop package，或者日志里混入了自定义调试语句（比如某人手写 echo "send_buffer_roll_back"）。
为什么搜不到 send_buffer_roll_back？
Workerman 官方源码、文档、Issue 和所有稳定版本中均不存在该字符串。它不是内置常量、错误码、函数名或事件回调名。你在日志里看到它，只有两种可能：
- 业务代码里某处手动
echo或error_log()输出了这串文字（例如在onBufferFull里写了error_log('send_buffer_roll_back')） - 日志被其他中间件、代理（如 Nginx 的 access_log 格式）、或监控 SDK 错误注入
先用 grep -r "send_buffer_roll_back" app/ workerman/ 定位来源，别急着调缓冲区参数。
onBufferFull 被触发的真实原因和必须做的两件事
真正的问题是 TcpConnection::$maxSendBufferSize（默认 1MB）被撑爆了：不是网络慢，而是你的业务发得太猛——比如每毫秒 $connection->send($big_json) 一次，或单次发送 >500KB 的二进制数据。
- 必须在
onBufferFull回调里立刻停发：$connection->isSending = false，并清空待发队列（如果用了队列） - 必须注册
onBufferDrain回调，在里面恢复发送：$connection->isSending = true，再检查队列是否还有未发数据 - 不能只打日志或
return——否则后续send()仍会执行，超出缓冲区的数据会被静默丢弃，最终触发error 2 - 不要在
onMessage中连续多次调用send()（如先发 header 再发 body），必须拼成完整字符串再一次性send($full_payload)
怎么验证是不是缓冲区真满了，而不是假警报？
加一行诊断日志到 onBufferFull：
$bufferSize = $connection->getSendBufferSize();
$maxSize = $connection::$maxSendBufferSize;
error_log("onBufferFull: current={$bufferSize}, max={$maxSize}, conn_id={$connection->id}");
观察输出：
- 如果
current稳定在接近max（比如 1048576 字节），说明确实是发送节奏压过了 TCP 写出速度 - 如果
current只有几 KB 就触发，那大概率是连接已断（$connection->isClosed()为 true），但你的业务还在往里塞数据 - 如果日志里根本没这行输出，但又看到 “roll_back” 字样——100% 是你自己的代码或第三方包打的
最易被忽略的一点：Workerman 的发送缓冲区是 per-connection 的，不是全局的。一个连接卡住，不会影响其他连接；但如果你在 onBufferFull 里只停了当前连接，却忘了清理关联的定时器、协程或异步任务，那些残留逻辑可能还在不断 push 数据到已满的缓冲区里。
