context.withcancel不能自动取消read/write，因io.reader/writer不感知context；仅net.conn、http.request.body等显式支持的类型才响应取消。
context.WithCancel 不能自动取消正在进行的 Read 或 Write
Go 的 io.Reader 和 io.Writer 接口本身不感知 context.Context，调用 Read 或 Write 时传入 context 并不会生效——除非底层实现显式支持（比如 net.Conn、http.Request.Body）。直接对普通文件或管道调用 Read，即使 context 已被 cancel，也会一直阻塞到系统调用返回。
常见错误现象：
- 启动 goroutine 读取大文件或慢网络流，然后调用 cancel()，但 goroutine 仍卡在 read(...) 不退出
- 误以为包一层 context.WithTimeout 就能中断任意 IO，结果超时后 Read 还在等数据
实操建议：
- ✅ 对网络连接（net.Conn）：调用 SetReadDeadline / SetWriteDeadline 配合 context 超时
- ✅ 对 http.Client：直接传入带 timeout 的 context.Context 到 Do 方法，它内部会处理连接与 body 读取的取消
- ❌ 不要对 os.File 的 Read 直接套 context——它不响应；如需取消，得用 syscall.Read + select + chan struct{} 手动轮询（极少见且复杂）
哪些标准库类型真正支持 context 取消
不是所有带 Context 参数的方法都“真正取消 IO”，关键看是否在阻塞点主动检查 ctx.Done() 并提前返回 context.Canceled 或 context.DeadlineExceeded。
真正支持的典型场景：
- http.Client.Do(req *http.Request)：整个请求生命周期（DNS、连接、TLS、发送、接收响应头/体）都会响应 context 取消
- net/http.Request.Body.Read：当底层是 http.http2transport 或启用了 http.Transport 的 IdleConnTimeout 等机制时，会响应 context
- database/sql.Rows.Next：依赖驱动实现，lib/pq 和 go-sql-driver/mysql 均支持 context 取消查询执行
- os/exec.Cmd.Run / Start：不支持；但 Cmd.Wait 可配合 select + ctx.Done() 实现超时等待
容易踩的坑：
- 把 io.Copy 包进 select 里想取消？不行——它内部是循环调用 Read/Write，不检查 context
- 用 io.MultiReader 或 io.TeeReader 组合多个 reader？它们也不透传 context，取消逻辑必须由最外层控制
自己封装可取消的 Reader/Writer 要注意什么
如果你需要让自定义 IO 类型响应 context，核心是在每次 Read / Write 中做两件事：检查 ctx.Err()，并在阻塞前把 ctx.Done() 传给下层可取消操作（如 channel receive、net.Conn.Read）。
实操要点：
- 不要在 Read 开头就检查 ctx.Err() 然后立即返回——这会跳过已缓存数据或部分读取状态
- 如果底层是 net.Conn，优先用 SetReadDeadline，比轮询 ctx.Done() 更高效、更可靠
- 若必须轮询（比如封装 os.PipeReader），用 select 包裹 read syscall 和 ctx.Done()，但注意：Linux 的 read 在 pipe 关闭前不会因信号中断，所以还需监听 pipeReader.Close 或额外 done channel
- 返回错误时统一用 ctx.Err()，不要返回 io.EOF 或其他伪装值，否则上层无法区分是自然结束还是被取消
简短示例（简化版可取消 pipe reader）：
func (r *cancellableReader) Read(p []byte) (n int, err error) {
select {
case <-r.ctx.Done():
return 0, r.ctx.Err()
default:
}
return r.reader.Read(p) // 假设 r.reader 是 *io.PipeReader，实际中需用 syscall.Read + select 处理
}
取消后资源没释放？多半是没关底层连接或没等 goroutine 退出
context 取消只是发信号，不负责清理。常见漏掉的动作：
- http.Response.Body 没调用 Close() → 连接复用池卡住，后续请求变慢
- net.Conn 没 Close() → 文件描述符泄漏
- 启动了 goroutine 做 IO，取消后没同步等待它退出 → 数据竞态或 panic（比如往已 close 的 channel 写）
实操建议：
- 总是在 defer resp.Body.Close() 后再检查 resp.StatusCode，哪怕 context 已取消
- 对自定义 IO goroutine，用 sync.WaitGroup 或 chan struct{} 显式通知退出，不要只靠 context
- 使用 io.SectionsReader 或 bytes.Reader 时不用关，但用 os.Open 后的 *os.File 必须 Close
性能影响提示：频繁创建/取消 context 对 CPU 影响极小，但若每个请求都新建 http.Client（而非复用带连接池的全局 client），反而会放大 fd 和 TLS 握手开销——取消机制本身不是瓶颈，滥用才是。
立即学习“go语言免费学习笔记（深入）”；
最常被忽略的一点：取消信号到达后，IO 操作可能已经完成了一半（比如读了 1024 字节中的前 512 字节），此时 Read 返回 n=512, err=context.Canceled ——你得处理这部分有效数据，而不是直接丢弃。
