Go TLS Handshake 卡住的典型表现是客户端发起 HTTPS 请求后阻塞在连接建立阶段，或 tls.Conn.Handshake() 永久阻塞、strace 显示停在 recvfrom/poll，且无错误无超时；根本原因是默认 socket 未设读写 deadline，Handshake() 依赖底层 I/O 而不自带超时，需手动配置 SetReadDeadline/SetWriteDeadline 或 Transport.TLSHandshakeTimeout。
Go TLS Handshake 卡住的典型表现
服务启动后监听了端口，但客户端一发起 HTTPS 请求就卡在连接建立阶段；或调用 tls.Client.Handshake() 后 goroutine 永久阻塞，strace 显示停在 recvfrom 或 poll；日志里既无错误也无超时提示，Ctrl+C 也无法中断——这是典型的 TLS 握手未完成且无超时控制的表现。
为什么 tls.Conn.Handshake() 会无限等待？
根本原因不是 Go 实现有 bug，而是 Handshake() 是阻塞调用，它依赖底层 socket 的读写行为，而默认 socket 没设任何超时：
-
Dial成功只表示 TCP 连通，不保证 TLS 层能完成协商 - 若对端不响应 ServerHello、证书链不全、SNI 不匹配或中间设备（如 WAF、代理）静默丢包，
Handshake()就会一直等 - 标准库没有内置 handshake 超时，必须手动加
SetReadDeadline/SetWriteDeadline - 使用
http.Client时，TLSHandshakeTimeout字段就是专为这个场景设计的，但很多人漏配
Go 客户端 TLS 连接超时的正确写法
不要直接 tls.Client(conn, cfg).Handshake()，要包裹超时控制：
- 对裸
net.Conn：在调用Handshake()前执行conn.SetReadDeadline(time.Now().Add(5 * time.Second))和conn.SetWriteDeadline(...) - 对
http.Client：必须显式配置Transport.TLSHandshakeTimeout，仅设Timeout不生效 - 避免复用已失效的
*tls.Conn：比如从连接池取出后未检查是否已关闭，再调Handshake()会 panic 或卡死 - 注意
tls.Config.ServerName是否设置正确——若目标是 IP 地址，需设为空字符串或对应域名，否则握手可能失败且不报错
服务端 STARTTLS 升级后卡住的坑
SMTP/IMAP 等协议常用 STARTTLS，在明文连接上动态升级为 TLS。这里最容易忽略的是升级后的连接替换逻辑：
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
s.Conn = net.Conn(tlsConn)—— 强制类型转换丢失 TLS 状态，后续 I/O 行为不可预测 - 正确写法：
s.Conn = tlsConn（直接赋值*tls.Conn），并确保Handshake()成功后再替换 - 升级后没重置
bufio.Reader/Writer缓冲区，残留明文数据导致 TLS 解密失败，表现为“卡住”而非报错 - 内核 netlink 阻塞也可能干扰 handshake（尤其容器环境），若
strace显示卡在recvfrom且套接字是 netlink 类型，需按 netlink 超时方案处理
真正难排查的不是 handshake 失败，而是它不失败也不返回——这种静默挂起往往源于 deadline 漏设、SNI 错配或内核态阻塞叠加，必须逐层验证 socket 状态、TLS 参数和系统调用栈。
