Go 中无带超时的I/O多路复用API；超时必须设在连接/读写/请求层，通过SetReadDeadline/SetWriteDeadline或http.Client+context实现，不可用select+time.After中断阻塞Read。
Go 语言中不存在“带超时限制的 I/O 多路复用函数”这种用户可直接调用的 API。标准库不提供类似 epoll_wait 或 select 加超时参数的裸系统调用封装，也不鼓励你手动介入 netpoll 底层。真正的超时控制必须落在连接、读写、请求三个层级，且需与 Go 的 goroutine 调度协同，否则会绕过 runtime.netpoll，导致阻塞或性能断崖。
conn.Read/Write 超时必须用 SetReadDeadline 和 SetWriteDeadline
很多人试图在 select 里套 conn.Read 并配 time.After，这是常见误区——conn.Read 本身是阻塞调用，一旦进入就脱离调度器控制，select 无法中断它。正确做法是提前设置截止时间：
-
conn.SetReadDeadline和conn.SetWriteDeadline是唯一可靠方式，它们让底层 netpoll 在超时后主动唤醒 goroutine 并返回net.ErrTimeout - 每次读写前都必须重设 deadline，因为它是“一次性”的：一次
Read返回后，deadline 自动失效 - 不要混用
SetDeadline（同时影响读写）和单独的 Read/Write 版本，容易因逻辑覆盖导致意外阻塞 - 若连接是 TLS 封装的（如
tls.Conn），同样支持这两个方法，无需额外处理
HTTP 客户端超时必须靠 http.Client + context
直接用 http.Get 或 http.Post 没有超时控制，低速网络下可能卡死数分钟。必须显式构造 http.Client 并注入 context.Context：
-
http.Client.Timeout只控制整个请求生命周期（含 DNS、连接、读响应体），但无法中断正在读取的大响应体 - 更细粒度的做法是用
ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)，再传给client.Do(req.WithContext(ctx)) - 如果服务端流式返回（如 SSE、长轮询），仅靠
Client.Timeout不够，必须在读取响应体时配合resp.Body.Read+SetReadDeadline - 避免在 handler 中复用同一个
http.Client实例却不设 Timeout：默认无超时，故障时会堆积 goroutine
低速网络下，别用 select + channel 模拟 I/O 超时
有人写这样的代码：
select {
case data := <-readChan:
// 处理数据
case <-time.After(5 * time.Second):
return errors.New("timeout")
}这看似优雅，实则危险：
- 如果
readChan来自一个阻塞conn.Read启动的 goroutine，那么time.After触发时，那个 goroutine 仍在内核等待，fd 未关闭，资源泄漏 - channel 本身不携带超时语义；它只是传递结果，超时逻辑必须在 I/O 操作发起侧完成
- 真正需要多路复用多个连接时，应让每个连接独立设置 deadline，并用
select等待多个chan error（来自各自 goroutine 的完成通知），而非试图对 I/O 动作本身做非阻塞包装
net.Dial 超时必须通过 net.Dialer 显式配置
DNS 解析和 TCP 连接阶段最容易被忽略，尤其在弱网或 DNS 故障时，net.Dial("tcp", host, port) 可能卡住几十秒。不能依赖 context.WithTimeout 包裹整个 dial 过程——它只 kill goroutine，不 cancel 底层系统调用：
立即学习“go语言免费学习笔记（深入）”；
- 必须用
&net.Dialer{Timeout: 3 * time.Second, KeepAlive: 30 * time.Second}构造 dialer - 搭配
net.Dialer.Resolver可控制 DNS 查询行为，例如禁用系统解析器、改用 UDP 查询或设置 DNS 超时 - 若使用
http.Transport，记得把自定义 dialer 赋给Transport.DialContext字段，而不是只设Client.Timeout - 注意：
Dialer.KeepAlive是 TCP 层保活，不影响首次连接超时，别把它和Timeout搞混
最易被忽略的一点：所有 deadline 设置（Read/Write/Dial）都基于系统时钟，若客户端机器时间跳变（如 NTP 校正），可能触发误超时。生产环境建议用单调时钟（time.Now().Add 生成 deadline 是安全的，因为 Go 内部用的是 monotonic clock）。
