net.Conn 接口及其所有标准实现的 Read/Write 方法均不支持 Context，握手阶段的超时与取消必须通过 Dialer.DialContext 或 http.Client 的 Request.Context() 在连接发起时绑定，而非在 Conn 上添加。
Go 的 net.Conn 不支持在握手阶段传入 Context
直接说结论：net.Conn 接口本身没有上下文（Context）参数，标准库中所有实现（如 tcpConn、unixConn）的 Read/Write 方法都不接受 Context。握手阶段（比如 TCP 连接建立、TLS 握手）更不提供原生 Context 支持——这不是遗漏，而是设计使然：底层 socket 操作由操作系统完成，Go 的 net 包封装的是阻塞式 I/O 模型。
想中断连接建立？用 Dialer.WithContext 而不是往 Conn 里塞 Context
TCP 连接和 TLS 握手的超时/取消，必须在「发起连接」那一刻就绑定 Context，而不是等拿到 net.Conn 后再想办法。关键入口是 net.Dialer 和 tls.Config 中的可配置字段：
-
Dialer.Timeout和Dialer.KeepAlive只控制底层 TCP 行为，不响应 cancel - 真正支持 cancel 的是
Dialer.DialContext—— 它会在 DNS 解析、TCP 连接、TLS 握手全过程监听Context.Done() - 对 TLS，还需确保
tls.Config.GetClientCertificate等回调函数内部不阻塞，否则会卡住整个握手
示例：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
<p>dialer := &net.Dialer{Timeout: 3 * time.Second}
conn, err := tls.Dial("tcp", "example.com:443", &tls.Config{}, dialer.DialContext(ctx, "tcp", "example.com:443"))注意：tls.Dial 第四个参数是 func(ctx context.Context, network, addr string) (net.Conn, error)，这里传入 dialer.DialContext(ctx, ...) 才真正启用上下文取消。
立即学习“go语言免费学习笔记（深入）”；
HTTP 客户端自动继承 Context，但底层仍靠 DialContext
如果你用的是 http.Client，它的 Do 方法接收 *http.Request，而 Request.Context() 会被透传到底层 Transport 的连接建立逻辑中——前提是 Transport.DialContext 被正确设置：
- 默认
http.DefaultTransport已设置DialContext，所以普通http.Get或带context.WithTimeout的请求能正常中断连接建立 - 若自定义
http.Transport，必须显式赋值DialContext字段，否则Context在握手阶段完全失效 -
Transport.TLSHandshakeTimeout是独立于 Context 的硬超时，它不会触发 cancel，仅用于兜底
自己封装 Conn 时别试图“加 Context”到 Read/Write
有人会想包装 net.Conn，给 Read/Write 加 Context 参数。这不可行：
- 违反
net.Conn接口契约，无法被标准库（如http.Server、bufio.Reader）消费 - TLS 层（
tls.Conn）的Read/Write也不接受Context，你没法在加密数据流中插入取消信号 - 真正的取消只能发生在系统调用层级（如
connect()、read()返回EINTR或EAGAIN），Go 运行时已通过runtime.netpoll封装了这部分逻辑，用户无需、也不能绕过
需要细粒度控制读写超时？用 SetDeadline / SetReadDeadline，它们作用于 socket fd 本身，和 Context 无关但更底层可靠。
真正容易被忽略的点是：Context 取消只影响「尚未开始」或「正在执行但未返回」的系统调用；如果 TLS 握手已进入密钥交换阶段，cancel 可能要等到下一次 read/write 才生效——这不是 bug，是 OS I/O 模型决定的边界。
