go中禁用tcp deadline的正确方式是传零值time.time{}，而非极大时间；setdeadline同时控制读写，setread/writedeadline可独立设置，且频繁调用线程安全。
Go 里设 deadline 不是“开个开关”那么简单，关键在两点：一是用对函数和参数，二是理解“禁用”不是靠“设成极大值”，而是传零值 time.Time{}。
SetDeadline、SetReadDeadline、SetWriteDeadline 的区别
这三个函数都作用于 net.Conn（比如 *net.TCPConn），但控制粒度不同：
-
SetDeadline(t)同时影响后续所有读和写操作； -
SetReadDeadline(t)只约束Read类调用（如conn.Read()）； -
SetWriteDeadline(t)只约束Write类调用（如conn.Write()）。
实际业务中更推荐分开设——比如心跳只关心读超时，大文件上传可能要放宽写超时，而读仍需严格限制。
如何真正禁用已设置的 deadline
别用 time.Now().Add(100 * 365 * 24 * time.Hour) 或 time.Unix(0, 0)，它们都是有效时间点，会导致意外超时或精度漂移。
唯一被标准库识别为“禁用”的方式是传入零值：
conn.SetDeadline(time.Time{})conn.SetReadDeadline(time.Time{})conn.SetWriteDeadline(time.Time{})
这个 time.Time{} 是类型零值（等价于 time.Unix(0, 0).UTC()），底层网络栈明确将其解释为“无截止时间”，连接会退回到阻塞行为（除非你另外设置了 SetNonblock(true)）。
频繁修改 deadline 安不安全
完全安全。每次调用只是更新 socket 的 SO_RCVTIMEO 或 SO_SNDTIMEO 内核选项，无锁、无内存分配、无竞态风险。
但要注意两个边界情况：
- 如果连接已经因超时关闭（比如
read: i/o timeout），再调SetDeadline会返回os.ErrClosed，应提前检查错误； - 多个 goroutine 并发调同一连接的 deadline 方法时，虽线程安全，但逻辑上可能互相覆盖——建议由单个协程统一管理，或加简单状态锁。
context.WithDeadline 和 net.Conn deadline 是一回事吗
不是。它们完全独立：
-
context.WithDeadline控制的是 Go 协程生命周期，靠ctx.Done()通道通知，需要你手动检查ctx.Err()才能退出； -
net.Conn.SetXXXDeadline是操作系统级 socket 超时，触发的是底层read()/write()系统调用立即返回错误（如i/o timeout）。
典型组合用法是：用 context 控制整体请求生命周期，用 conn deadline 控制单次 I/O 响应窗口。两者叠加时，conn.Read() 若同时接受 context.Context（如 http.Request.Context() 或 net.Conn.Read() 的封装层），会优先响应 context 取消；否则只看 socket deadline。
最易忽略的一点：deadline 不是“倒计时器”，它绑定的是绝对时间点。一旦系统时钟跳变（比如 NTP 校正或容器时钟漂移），就可能提前或延后触发——生产环境务必监控节点时钟偏移。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
