检测连接断开应以recv()返回0或特定errno为准，而非仅依赖send()返回值；需主动探测、分离重连逻辑、控制connect()超时、同步会话状态。
检测连接是否断开：别只靠 send() 返回值
很多人以为 send() 返回 -1 就代表断线，其实不然——它可能只是缓冲区满、被信号中断（EINTR），甚至在非阻塞模式下返回 EAGAIN/EWOULDBLOCK。真正在意的“断线”信号，往往来自 recv()：当它返回 0，说明对端已正常关闭连接（FIN）；返回 -1 且 errno 是 ECONNRESET、ETIMEDOUT 或 ENOTCONN，才大概率是异常断开。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每次读写后都检查
recv()和send()的返回值，不只看是否为 -1，更要结合errno - 不要依赖心跳包前的“连接还活着”假设——TCP 连接空闲时不会自动通知你它已失效，必须主动探测（如发心跳或启用
SO_KEEPALIVE） - 若用
select()/poll()等 I/O 多路复用，注意它们对“对端关闭”的就绪判断：recv()返回 0 时，该 socket 仍可能被标记为可读，需立刻处理
重连逻辑放哪：别塞进业务线程里硬等
把重连逻辑和主通信逻辑耦合在同一个线程里，容易导致整个业务卡死（比如重试间隔设成 5 秒，期间啥也干不了）。更合理的方式是分离职责：用独立线程或定时器驱动重连，主循环只管收发。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用一个原子标志（如
std::atomic<bool> connected{false}</bool>）标记当前连接状态，所有模块通过它感知连通性 - 重连线程应带退避策略，例如指数退避：
retry_delay = std::min(30000, base_delay * (2^attempt))，避免雪崩式重连请求 - 重连前先
close()旧 socket（即使已无效），防止 fd 泄漏；重连成功后，重置序列号、会话状态等上下文，别直接复用旧对象
connect() 超时控制：系统默认会卡住 75 秒
默认阻塞模式下，connect() 在无响应时可能阻塞长达 75 秒（Linux 默认 SYN 重传 6 次，间隔指数增长），这完全不可接受。必须手动控制超时。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 将 socket 设为非阻塞（
fcntl(sockfd, F_SETFL, O_NONBLOCK)），再调用connect()；它会立即返回 -1 并设errno = EINPROGRESS - 用
select()或poll()等待 socket 变为可写（注意：可写表示 connect 完成，无论成功或失败） - 完成后用
getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &err, &len)获取真实错误码，err == 0才算真正连上
重连时的状态同步：别让新连接继承旧会话的“幻觉”
重连不是简单地重建 socket，而是重建会话语义。如果服务端维护了 session ID、消息序号、未确认的指令等状态，客户端重连后没同步，就会出现丢指令、重复提交、认证失败等问题。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每次重连成功后，强制执行一次握手协议（如发送
HELLO帧，携带 client ID 和上次 seq_no），由服务端决定是否续接会话 - 本地缓存未 ACK 的业务消息（用队列 + 定时重发），重连后按序重推，而不是清空重来
- 若协议支持，让服务端在断连时保留 session 若干秒（如 30s），给客户端留出重连窗口；超时则返回
SESSION_EXPIRED错误，客户端需走完整登录流程
真正难的不是重连代码本身，而是怎么定义“重连成功”——是 socket 可写？是收到第一个 ACK？还是服务端返回了有效的会话令牌？这个边界模糊点，往往藏在协议文档第 17 行小字里。
