connect()超时不能用alarm()或sleep()，因前者多线程不可靠、后者无法中断系统调用；正确做法是设socket为非阻塞，用select()/poll()等待可写后通过getsockopt()检查so_error。
connect() 超时为什么不能直接用 alarm() 或 sleep()
因为 connect() 在阻塞模式下是同步调用，会卡住整个线程，alarm() 信号在多线程里不可靠，sleep() 又无法中断正在进行的系统调用。真正可控的方式是把 socket 设为非阻塞，再配合 select() 或 poll() 等待可写状态。
常见错误现象：用 setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, ...) 想控制 connect() 超时——没用，这个选项只影响 recv()/send()，对 connect() 完全无效。
- 必须先调用
fcntl(sockfd, F_SETFL, O_NONBLOCK)把 socket 设为非阻塞 - 调用
connect()后，如果返回 -1 且errno == EINPROGRESS，说明连接正在后台进行 - 接着用
select()等待该 socket 变成“可写”（注意：不是“可读”，connect 完成后触发的是可写事件） - select 返回后，用
getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &err, &len)检查是否真的连成功了（err == 0才算）
非阻塞 connect + select 的最小可行代码结构
下面这段逻辑能跑通，但要注意几个关键参数和边界：
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
fcntl(sockfd, F_SETFL, O_NONBLOCK);
struct sockaddr_in addr = {0};
addr.sin_family = AF_INET;
addr.sin_port = htons(80);
inet_pton(AF_INET, "1.2.3.4", &addr.sin_addr);
// 第一次 connect，非阻塞下立即返回
if (connect(sockfd, (struct sockaddr*)&addr, sizeof(addr)) == -1) {
if (errno != EINPROGRESS) {
// 真出错了，比如地址格式不对
close(sockfd);
return -1;
}
// 继续等待
}
fd_set writefds;
struct timeval tv = {3, 0}; // 3秒超时
FD_ZERO(&writefds);
FD_SET(sockfd, &writefds);
int ret = select(sockfd + 1, NULL, &writefds, NULL, &tv);
if (ret == 0) {
// 超时
close(sockfd);
return -1;
}
if (ret == -1) {
// select 自身出错
close(sockfd);
return -1;
}
// 检查 connect 实际结果
int err = 0;
socklen_t len = sizeof(err);
if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, &err, &len) == -1 || err != 0) {
close(sockfd);
return -1;
}
// 到这里才算真正连上了
注意：select() 第一个参数是最大 fd + 1，别传错；SO_ERROR 必须在 select() 返回可写之后读，否则可能拿到旧值。
立即学习“C++免费学习笔记（深入）”；
Linux 和 macOS 上的 poll() 替代方案差异
poll() 比 select() 更简洁，但 macOS 对 POLLOUT 的语义处理和 Linux 不完全一致：Linux 下 connect 完成后一定触发 POLLOUT，macOS 有时会多触发一次，或在失败时也触发。所以检查结果仍必须依赖 getsockopt(sockfd, SOL_SOCKET, SO_ERROR, ...)，不能只看 poll() 返回的事件类型。
- 用
pollfd.fd = sockfd，pollfd.events = POLLOUT - 调用
poll(&pollfd, 1, timeout_ms)，返回值 > 0 才继续检查 - 即使
pollfd.revents & POLLOUT为真，也要调getsockopt(... SO_ERROR ...)确认 - Windows 不支持
poll()，得换用WSAEventSelect()或select()
超时精度、并发与资源泄漏风险
用 select() 或 poll() 做超时，实际精度受限于系统调度和内核 timer 分辨率，通常在 10ms 量级，别指望精确到毫秒级。更麻烦的是资源管理：如果超时发生但没 close socket，fd 会泄露；如果多个线程共用同一个 socket fd 去 connect，行为未定义。
- 每次非阻塞 connect 后，无论成功失败，都必须
close(sockfd)—— 即使 connect 失败，fd 也是打开状态 - 不要在循环里反复
connect()同一个 socket 而不 close，容易耗尽 fd 限额 - 高并发场景下，避免对每个连接都起一个线程配 select，改用 epoll（Linux）或 kqueue（macOS）批量管理
-
SO_RCVTIMEO和SO_SNDTIMEO是给后续 read/write 用的，跟 connect 超时无关，别混用
最易被忽略的一点：connect 非阻塞后，socket 状态其实还是未连接（getpeername() 会失败），直到 getsockopt(... SO_ERROR ...) 返回 0 才真正就绪——中间任何一步漏判，都会让后续 send/recv 出现 EPIPE 或 ENOTCONN。
