正常断开与异常掉线均表现为recv()返回0或-1，但需结合errno、心跳、超时及状态机综合判断：recv()==0标记“待确认关闭”，send()失败且errno为econnreset/epipe则立即释放，辅以应用层心跳与空闲超时，避免误判与资源泄漏。
在非阻塞 I/O（如 epoll、kqueue 或 Windows IOCP）中，客户端“正常断开”和“异常掉线”都表现为读事件就绪后 recv()（或 read()）返回 0 或负值，但二者语义不同：前者是对方主动调用 close() 或 shutdown(SHUT_WR)，后者可能是网络中断、进程崩溃、NAT 超时等。关键不在于“如何检测”，而在于“如何区分并响应得体”。
靠一次 recv() 返回值无法可靠区分断开类型
非阻塞 socket 上，recv(fd, buf, len, MSG_DONTWAIT) 可能返回：
- ＞0：收到数据，正常
- 0：对端已关闭写端（FIN 抵达），即“正常断开”的典型信号
-
−1，且
errno == EAGAIN/EWOULDBLOCK：无数据可读，连接仍活跃 -
−1，且
errno == ECONNRESET/EPIPE：对端异常重置（如强制 kill、崩溃），属“异常掉线” -
−1，且
errno == ETIMEDOUT/ENETDOWN/ENETUNREACH：底层网络故障，也属异常
注意：recv() == 0 并不绝对等于“对方友好退出”——中间设备（如防火墙、代理）也可能伪造 FIN；而某些异常（如静默丢包）可能长期不触发错误，仅表现为后续 send() 失败或超时。
结合读、写、心跳与超时做综合判断
单靠一次系统调用结果易误判。应构建多层验证机制：
-
读到 0 → 标记为“待确认关闭”：不立即清理资源，先停止读、暂停发送新业务数据，但允许发 FIN 响应（如 HTTP 的
Connection: close） -
写失败时检查 errno：若
send()返回 −1 且errno是EPIPE或ECONNRESET，基本可判定对端已消失，立刻释放连接 - 启用应用层心跳：例如每 30 秒发一次 ping，对方必须回 pong；连续 2 次未收到 pong → 主动断连。这能捕获“无 FIN 的静默掉线”
- 设置空闲超时（idle timeout）：从最后收/发时间起计时，超时未活动则关闭。避免僵尸连接堆积
状态机驱动连接生命周期管理
把连接抽象为有限状态（如 IDLE → ESTABLISHED → CLOSING → CLOSED），每个 I/O 事件触发状态迁移：
- 收到 FIN（
recv()==0）→ 迁入CLOSING，调用shutdown(SHUT_RD)，准备发 FIN - 写缓冲区清空后
send()成功 → 调用shutdown(SHUT_WR)，进入CLOSED - 心跳超时或
send()出错 → 跳过优雅流程，直接close() - 所有状态均需注册超时定时器，防止卡死
这样，正常断开走“四次挥手”路径，异常掉线走“强制终止”路径，逻辑清晰、资源可控。
避免常见陷阱
实际编码中容易踩坑：
-
不要忽略
recv()==0后的后续事件：epoll 可能继续通知可读，反复recv()会持续返回 0，应立刻epoll_ctl(DEL)或设为EPOLLIN & EPOLLOUT等待写就绪再关 -
不要在
recv()==0后立刻close()：若还有未发完的数据，会丢包；应先尝试 flush 发送缓冲区 -
慎用
SO_KEEPALIVE：系统级心跳间隔长（默认 2 小时）、不可控，仅作兜底，不能替代应用心跳 - 记录日志要带上下文：比如 “client 10.0.1.5:48231 closed gracefully (recv=0)” vs “client 10.0.1.5:48232 reset by peer (send: ECONNRESET)” —— 便于运维定位问题类型
不复杂但容易忽略。
