Swoole没有lingering_close配置项，因其基于事件驱动、连接由PHP代码显式控制；而Nginx的lingering_close是HTTP模块在C层实现的统一兜底机制，用于兼容不规范客户端，二者设计目标与抽象层级不同。
没有 lingering_close 指令，Swoole 不提供 Nginx 那套配置式延迟关闭机制。
为什么 Swoole 没有 lingering_close 配置项
Swoole 是基于事件驱动的异步网络库，连接生命周期由 PHP 代码显式控制；而 Nginx 的 lingering_close 是在 HTTP 模块中对 TCP 连接做统一兜底管理的 C 层逻辑。两者设计目标不同：
- Nginx 需要兼容各种“不守规矩”的客户端（比如旧浏览器、嵌入式设备），必须在协议栈之上补一层读缓冲等待逻辑
- Swoole 默认把连接控制权交给开发者：你调用
close($fd)就是立刻关，想延迟关就得自己写onClose里的定时器或defer逻辑 - Swoole 的
onClose触发时机本身已区分了 FIN 和 RST —— 收到 FIN 才走正常流程，RST 直接清理，不给你“ linger ”的机会
close($fd) 在 Swoole 中的实际行为
调用 close($fd) 时，Swoole 底层会立即执行 epoll_ctl(EPOLL_CTL_DEL) 并释放 fd 关联资源，不会等发送缓冲区清空：
- 如果内核 send buffer 还有未发出的数据，后续由 TCP 协议栈自行处理（可能发 FIN 后重传，也可能超时丢弃）
- 不会像 Nginx 那样主动进入“只读不写 + 超时关闭读”的 linger 状态
- 也不会设置
SO_LINGER选项 —— Swoole 初始化 socket 时就禁用了它（避免阻塞 event loop）
如何在 Swoole 中模拟类似 Nginx 的延迟关闭
真有需要（比如响应错误后确保客户端收到内容再断连），得手动实现，核心是绕过直接 close()：
- 先调用
$server->send($fd, $error_msg)发送数据 - 再用
$server->after($ms, function() use ($server, $fd) { $server->close($fd); })延迟关闭 - 或者监听
onBufferFull/onBufferEmpty配合getSocket()检查底层 write buffer 状态（需自行stream_socket_get_name()或socket_get_status()辅助判断） - 注意：不能在
onClose回调里再调close()，会导致重复清理和崩溃
真正容易被忽略的是：Swoole 的“连接关闭”本质是 fd 生命周期结束，而 Nginx 的 lingering_close 是在 fd 仍存活时做读状态挂起。这两者不在同一抽象层级上，硬对标只会误用资源模型。
