go高级架构师考察net.conn超时需每次i/o前重设setreaddeadline/setwritedeadline；http server中readtimeout已弃用，应改用readheadertimeout、idletimeout等分层配置，并配合timeouthandler或context控制全链路。
Go 高级架构师岗位在网络编程方向，核心考察点不是“会不会写 HTTP 服务”，而是能否在真实高并发、长连接、低延迟场景下控制底层行为——比如 net.Conn 的读写超时策略是否合理、http.Server 的 ReadTimeout 和 ReadHeaderTimeout 差异是否被误用、context.WithTimeout 在 http.RoundTripper 中是否真正生效。
HTTP Server 超时配置为什么总不生效？
常见现象是设置了 http.Server.ReadTimeout，但慢请求仍卡住连接、goroutine 不回收。根本原因是 Go 1.8+ 已弃用 ReadTimeout/WriteTimeout，它们只作用于单次读/写，无法覆盖整个请求生命周期（比如大文件上传中途停顿）。
- 必须改用
ReadHeaderTimeout（限制 Header 解析时间）、IdleTimeout（限制 Keep-Alive 空闲时间）、WriteTimeout（仅限响应写入，且不包含流式响应） -
TimeoutHandler是唯一能控制整条请求链路的机制，但它会强制关闭 response writer，不适合需要流式返回或自定义错误页的场景 - 真正可控的粒度在
net.Conn层：通过conn.SetReadDeadline+conn.SetWriteDeadline手动管理，配合http.Hijacker或自定义ResponseWriter
长连接场景下如何避免 goroutine 泄露？
典型场景是 WebSocket、gRPC stream、SSE 服务。泄露往往不是因为没调 defer wg.Done()，而是连接异常中断后，读/写 goroutine 仍在阻塞等待 I/O，且无外部信号终止。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 永远不要依赖
conn.Read的返回错误自动退出——网络闪断可能只返回临时错误（如syscall.EAGAIN），goroutine 会持续重试 - 必须绑定
context.Context：用conn.SetReadDeadline配合time.AfterFunc触发 cancel，或直接用context.WithDeadline控制整体生命周期 - 对每个连接启动两个 goroutine（读 + 写），用
sync.Once保证 close 信号只触发一次，避免重复关闭chan导致 panic
net/http.Transport 复用连接时的坑
默认 http.DefaultTransport 在高并发下容易成为瓶颈：空闲连接堆积、DNS 缓存过期、TLS 握手未复用。更隐蔽的问题是 MaxIdleConnsPerHost 设为 0 时，实际行为是「不限制」而非「禁用复用」，导致连接数失控。
-
MaxIdleConns控制全局空闲连接总数，MaxIdleConnsPerHost控制每 host 数量，两者需同时设置，否则后者无效 - DNS 缓存由
net.Resolver管理，默认无缓存；若使用自定义 resolver，需手动加 TTL 控制，否则每次请求都走 DNS 查询 - TLS 复用依赖
tls.Config.GetClientCertificate和tls.Config.VerifyPeerCertificate的实现，若其中调用了阻塞 IO（如查 DB），整个连接池会卡住
UDP 服务如何做连接抽象和超时控制？
UDP 本身无连接，但业务常需模拟“会话”（如 STUN、QUIC 底层、游戏心跳）。难点在于：没有像 TCP 那样的内建连接状态，超时判断全靠定时器驱动，极易因 goroutine 泛滥或 timer 泄露拖垮服务。
- 不要为每个 UDP 包起 goroutine：用固定数量 worker 从
*net.UDPConn的ReadFrom循环中取包，通过map[sessionID]*session管理会话状态 - session 超时不用
time.AfterFunc（易泄漏），改用time.Timer.Reset复用单个 timer，或引入sync.Pool管理 timer 实例 - 发送失败不可重试：UDP 无 ACK，重试只会放大网络压力；应记录日志并通知上层降级（如切 TCP 回退）
网络编程的复杂性不在语法，而在对操作系统网络栈行为的理解深度——比如 SO_KEEPALIVE 在云环境常被中间设备拦截，TCP_USER_TIMEOUT 在不同 Linux 内核版本语义不一致。这些细节不会出现在文档首页，但线上故障时，它们就是根因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
