2026大厂Golang高级研发网络编程面试真题-Golang-PHP中文网

Go网络编程需精准控制超时与连接：ReadTimeout已弃用，应分层使用ReadHeaderTimeout、IdleTimeout、WriteTimeout；net.Conn deadline需每次I/O前重设；goroutine泄露主因是未结合context处理阻塞读写；MaxIdleConnsPerHost=0反不限制复用，须配合MaxIdleConns使用。

2026大厂golang高级研发网络编程面试真题

Go 高级研发岗位在网络编程方向，不考“能不能跑通 HTTP 服务”，而是看你能不能在连接没断、请求卡住、goroutine 不退的现场，把底层行为掰开、看准、控住。

http.Server.ReadTimeout 为什么设了也不生效？

这是最常被误用的配置。Go 1.8 起 ReadTimeout 已被标记为 deprecated，它只限制单次 conn.Read() 的耗时，对整个请求生命周期（比如上传中途停顿）完全无效。

真正起作用的是这三个分层配置：

ReadHeaderTimeout：只管 Header 解析，超时后直接关闭连接，适合防慢速 HTTP 攻击
IdleTimeout：控制 Keep-Alive 空闲时间，避免连接长期挂起却不释放
WriteTimeout：仅约束响应写入阶段（不含流式响应），且不覆盖 header 写入

如果你要控制整条请求链路（比如大文件上传最多 30 秒），必须用 http.TimeoutHandler，但它会强制关闭 ResponseWriter，不适合需要自定义错误页或 SSE 场景。

net.Conn 层超时必须每次 I/O 前重设

Go 的 net.Conn 是无状态字节流，SetReadDeadline 和 SetWriteDeadline 设置一次只对下一次 I/O 生效。很多人以为设一次就“永久有效”，结果长连接中第二次读就永远阻塞。

正确做法是：每次调用 conn.Read() 或 conn.Write() 前，都重新调用对应 deadline 设置函数。

常见错误模式：

conn.SetReadDeadline(time.Now().Add(5 * time.Second))
n, err := conn.Read(buf) // ✅ 第一次有效
// ... 忘记重设
n, err = conn.Read(buf) // ❌ 第二次可能永远阻塞

更稳妥的做法是封装一层带 context 的读写逻辑，用 context.WithDeadline 统一控制生命周期，再配合 conn.SetReadDeadline 同步更新。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

长连接场景 goroutine 泄露的真实原因

泄露往往不是因为没写 defer wg.Done()，而是连接异常中断后，读/写 goroutine 仍在 conn.Read() 或 conn.Write() 上阻塞，且没有外部信号让它退出。

典型陷阱：

只依赖 err != nil 判断退出：网络闪断可能返回 syscall.EAGAIN 或 io.EOF，但 goroutine 仍继续循环
没绑定 context.Context：无法从外部触发取消，尤其在 WebSocket/gRPC stream/SSE 中极危险
重复关闭 channel 或 conn：多个 goroutine 同时检测到断连并执行 close(ch) 或 conn.Close()，导致 panic

推荐结构：每个连接启动两个 goroutine（读 + 写），用 sync.Once 保证 close 信号只触发一次；读 goroutine 用 select 监听 conn.Read 和 ctx.Done()；写 goroutine 用带缓冲 channel 接收数据，避免阻塞。