先直接说结论：`send_yield` 这个函数，在 Swoole 的任何稳定版本里都不存在。你没看错，它不存在。你之所以会看到“send_yield”这个说法，大概率是把几个截然不同的概念——协程的挂起行为、`send` 的返回值语义，以及某些旧版文档或社区里的误传——给搞混了。

那么，`send` 在发送缓冲区满了的时候，真实表现是什么？ 答案是：`send` 是一个**同步非阻塞**调用。它的行为完全取决于底层操作系统 socket 发送缓冲区的状态： - 返回 `true`：数据已经成功写入操作系统的 socket 发送缓冲区。注意，这里强调的是“写入缓冲区”，而不是对端已经收到。 - 返回 `null`：数据被临时保存在 Swoole 的应用层缓冲区里，等待下一次 reactor 事件轮询时，再尝试写入 socket 缓冲区。 - 返回 `false`：发送失败，通常是客户端断连、fd 无效，或者应用层缓冲区也满了（默认上限是 2MB）。 缓冲区满 ≠ 程序卡死。Swoole 内部会把没发出去的数据暂存在连接对象的应用层缓冲区，并在下一轮事件循环中自动重试。你没办法靠“加个 yield”来等着它发完，因为 `send` 本身压根就不会挂起当前协程，它只是一个立即返回的函数。 为什么有人会误以为存在 `send_yield`？ 这个误会通常来自两类情况： 第一种，是把 `sendwait` 当成了 `send_yield`。`sendwait` 是阻塞式发送，它底层调用 `write()` 直到数据写完或出错，会让当前协程真正等待。但问题在于，它**不感知缓冲区水平**，不做流量控制，生产环境里用这个，很容易拖垮整个协程调度器，所以应该避免使用。 第二种，是有人手动写循环来模拟背压等待。比如 `while ($server->send($fd, $data) === null) { Co::sleep(0.001); }`。这看起来像是在“yield 等待”，但实际上效率非常低，精度也差，还掩盖了问题根源。 所以，真正的应对思路是什么？ 要应对发送缓冲区压力，有几种思路是经过验证的： - **主动降速**：监听 `onBufferFull` 回调。当连接缓冲区快满时，暂停投递新数据，比如暂停推送、降低心跳频率。 - **启用自动限流**：通过 `buffer_high_watermark` 和 `buffer_low_watermark` 配合 `onBufferFull` / `onBufferEmpty` 实现闭环控制，让系统自动调节。 - **拆大包为小包**：单次 `send` 的数据不要超过 64KB，避免触发内核分片或应用层缓冲区膨胀。 - **检查客户端消费能力**：如果对方接收很慢——比如弱网设备、没有及时 `recv`——那你的 `send` 再快也没意义。这时应该考虑在业务层引入 ACK 或滑动窗口机制。 总结一下：`send` 不会自动 yield，也不会因为缓冲区满就挂起协程。它只返回 `null` 表示“这次没发出去，我记下了，下次再试”。真正的背压控制，必须由你显式设计，而不是依赖一个不存在的 `send_yield`。