SO_SNDTIMEO和SO_RCVTIMEO对非阻塞socket无效，仅对阻塞socket生效；connect()超时需用非阻塞+select/poll实现，因二者不控制connect本身，其默认超时由TCP重传机制决定（约75秒）。
setsockopt 设置 SO_SNDTIMEO 和 SO_RCVTIMEO 为什么有时不生效
这两个选项在 Linux 上对阻塞 socket 有效，但对非阻塞 socket 完全忽略——这是最常踩的坑。如果你调用 connect() 后立刻设超时，而 socket 是非阻塞的（比如用了 O_NONBLOCK），那 send() 和 recv() 会直接返回 -1 并置 errno 为 EAGAIN/EWOULDBLOCK，根本不会等超时。
实操建议：
- 确认 socket 处于阻塞模式：创建后没调
fcntl(fd, F_SETFL, O_NONBLOCK)，或显式清除了该标志 - 超时值用
struct timeval，单位是秒+微秒，不是毫秒；设成{3, 500000}表示 3.5 秒 - 必须在
connect()成功之后、send()/recv()之前设置，否则部分系统（如旧版 macOS）可能拒绝应用 - Windows 上对应选项是
SO_SNDTIMEO和SO_RCVTIMEO，但值类型是DWORD（毫秒），且仅对阻塞 socket 生效
connect() 超时怎么安全控制
connect() 本身不支持超时参数，直接阻塞直到完成或失败。强行用 alarm() 不安全（信号中断可能破坏 errno 或导致竞态），推荐用非阻塞 + select() 或 poll()。
典型做法：
立即学习“C++免费学习笔记（深入）”；
- 创建 socket 后立即设为非阻塞：
fcntl(sockfd, F_SETFL, O_NONBLOCK) - 调用
connect(sockfd, ...)—— 它会立刻返回-1，errno为EINPROGRESS - 用
select()等待写就绪（注意：连接完成时 socket 可写）或超时 - 连接完成后，记得恢复为阻塞模式（如果后续要用
SO_SNDTIMEO），或继续用非阻塞 +select()控制收发
示例关键片段：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
int flags = fcntl(sockfd, F_GETFL, 0); fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); connect(sockfd, (struct sockaddr*)&addr, sizeof(addr)); // ... 然后 select() 等待
Linux 下 send() / recv() 超时的实际行为差异
即使设置了 SO_SNDTIMEO，send() 在内核发送缓冲区有空闲时会立刻拷贝数据并返回成功，不等待对方接收；只有缓冲区满、需等待 TCP 窗口更新时，才真正触发超时。同理，recv() 超时只针对“等待数据到达”，不包括“等待应用层完整报文”（比如你期望读 1024 字节，但只收到 100 字节，它不会等满才返回）。
这意味着：
- 超时不是端到端延迟保障，不能替代应用层心跳或协议级超时
- 小包高频发送时，
SO_SNDTIMEO很难触发；大块数据写入受阻时才可能生效 - 若需精确控制单次读取长度，必须循环调用
recv()并检查返回值，不能依赖一次调用读完
跨平台兼容性要注意的点
Windows 和 Linux 对超时语义基本一致，但 macOS 的 SO_RCVTIMEO 在某些版本中对 read() 无效（仍需用 select()）。更麻烦的是，Android NDK 的 Bionic libc 曾长期不支持 SO_SNDTIMEO（直到 API 29+ 才修复）。
稳妥方案：
- 优先使用非阻塞 socket +
select()/poll()，逻辑统一、可控性强 - 若坚持用阻塞 socket，务必在各平台验证超时是否真实触发（比如关掉对端网络再测试）
- 不要假设
setsockopt(..., SO_SNDTIMEO, ...)调用成功就等于超时已启用——加一句getsockopt()回读验证值是否被接受
真正麻烦的从来不是设个结构体，而是超时边界在哪：是连接建立？是数据发出？还是对方确认？得先想清楚你要卡哪一环，再选工具。
