Go crypto/tls HandshakeContext 如何响应取消：握手时机、超时与连接状态

Go 客户端连接 HTTPS 服务时，TCP 已经建立并不等于 TLS 已经可用。crypto/tls.Conn.HandshakeContext 让握手阶段也能接收取消信号：如果上游超时，握手会尽快返回错误；如果握手已经结束，之后的读写不会因为这个 context 自动停止。

把 HandshakeContext 当成“只覆盖握手阶段的取消边界”，再用连接关闭和读写超时覆盖后续生命周期，判断结果才不会失真。

先把 TLS 连接的三个阶段分开

一个 HTTPS 请求至少经历 TCP 建连、TLS 握手和应用层读写。这里把第一段记作 TCP connection，把最后一段记作 application read/write。tls.Client 只负责把底层连接包装成 TLS 连接，真正协商证书、密码套件并切换到可读写状态，发生在 Handshake 或第一次读写时。

这也是排查超时的关键：context 只传给 HandshakeContext，并不会成为连接对象的永久取消开关。握手成功后，即使 context 已经取消，连接仍可能继续读写。

最小写法：把握手错误当成连接不可用

下面的客户端显式调用 HandshakeContext，并把所有权写在同一段代码里：无论握手成功或失败，函数返回前都关闭连接。示例不依赖真实服务，重点是控制流和错误边界。

func dialTLS(ctx context.Context, addr string) error {
    raw, err := net.Dialer{}.DialContext(ctx, "tcp", addr)
    if err != nil {
        return err
    }
    conn := tls.Client(raw, &tls.Config{ServerName: "example.com"})
    defer conn.Close()

    if err := conn.HandshakeContext(ctx); err != nil {
        return err
    }
    return nil
}

这里有两个容易漏掉的细节。第一，DialContext 只负责 TCP 建连，不能代替 TLS 握手的取消控制。第二，HandshakeContext 返回 nil 只说明握手完成，不代表后面的 HTTP 请求已经成功。

取消发生在不同时间，结果为什么不同

握手开始前就取消

如果 ctx.Done 已经关闭，调用通常会很快返回 context 错误。此时不要把它归因于证书校验失败；应先看 errors.Is(err, context.Canceled) 或 errors.Is(err, context.DeadlineExceeded)。

握手进行中取消

握手需要等待对端的证书和协商报文。取消发生在等待期间时，调用返回非 nil 错误，底层连接不应再复用。即使连接对象仍在内存中，也不能把它当成可用的 TLS 会话。

握手成功后取消

这时 HandshakeContext 已经返回 nil，context 的职责结束。后续 conn.Write 或 conn.Read 是否停止，取决于读写 deadline、对端断开或显式 Close，不会被之前的 context 自动打断。

超时要覆盖完整生命周期

实际请求常把总预算拆成“建连与握手预算”和“应用读写预算”。前者传给 DialContext 与 HandshakeContext；后者用 SetDeadline，或者让更高层 HTTP 客户端用请求 context 管理请求。

deadline := time.Now().Add(2 * time.Second)
if err := conn.SetDeadline(deadline); err != nil {
    return err
}
if err := conn.HandshakeContext(ctx); err != nil {
    return err
}
// 握手后的读写仍受 deadline 约束

如果只给 context 设置 2 秒，却没有给握手成功后的读写设置边界，连接仍可能在业务阶段长时间卡住。相反，deadline 会影响后续 I/O，使用完连接后要按业务需要清理或更新它。

常见误区与复查清单

• 把 tls.Client 当成已经完成握手：应显式调用 HandshakeContext，或确认第一次读写的错误归属。
• 握手失败后继续放回连接池：失败连接必须关闭，不能复用。
• 用握手 context 控制整个请求：握手成功后另设读写 deadline 或请求级取消。
• 只检查字符串错误：优先使用 errors.Is 判断取消和 deadline，再记录原始错误。

相关问题

HandshakeContext 成功后取消 context，连接会自动关闭吗？

不会。它只约束握手调用；连接关闭需要显式 Close，或由后续 I/O 超时和上层连接管理逻辑触发。

握手失败还能重试同一个 tls.Conn 吗？

不建议。把底层连接和 TLS 状态视为失败实例，关闭后重新建立 TCP 连接，再创建新的 tls.Conn。

小结

HandshakeContext 解决的是 TLS 协商阶段的等待问题，不是整条连接的生命周期管理。可靠的做法是让建连、握手、应用读写分别拥有清晰的取消或超时边界，并在握手错误时立即关闭连接。