io.Copy卡住因默认阻塞等EOF，网络连接可能不关也不发数据；须设net.Conn的SetReadDeadline超时，或用带超时的io.ReadWriter包装。
为什么 io.Copy 会卡住，而你没看到错误？
因为 io.Copy 默认阻塞等待 EOF，但网络连接可能既不写入数据也不关闭（比如服务端发一半就挂了、心跳超时未处理）。此时调用方看似“卡死”，实际是底层 Read 在等待更多字节。
- 务必为底层
net.Conn设置SetReadDeadline或SetDeadline，否则超时控制完全失效 - 避免直接对裸
net.Conn调用io.Copy；优先包装成带超时的io.ReadWriter - 若需细粒度控制（如解析 HTTP 流），改用
bufio.Reader+ReadSlice或ReadBytes，并手动检查err == io.EOF与err == net.ErrClosed
如何让 http.Response.Body 支持流式解析又不泄漏 goroutine？
HTTP 响应体是 io.ReadCloser，但默认不支持中断或限速。直接 io.Copy 到 os.Stdout 看似简单，一旦下游写慢（比如终端卡顿），上游 TCP 窗口会被压满，导致服务端停止发送 —— 这不是 bug，是 TCP 流控生效。
- 用
io.LimitReader(resp.Body, maxBytes)防止 OOM，尤其处理未知大小的响应 - 若需边读边解析 JSON 流，用
json.NewDecoder(body).Decode(&v)，它内部按需调用Read，不会预加载整块 - 必须显式调用
resp.Body.Close()，否则底层连接无法复用（http.Transport会等它关闭才放回连接池）
context.WithTimeout 对 net.Conn 有效吗？
无效。Context 超时只影响 http.Client.Do 这类高层函数的发起阶段，不影响已建立连接上的读写。真正起作用的是连接自身的 deadline 设置。
