Golang 封装文件读写的上下文取消机制

先说几个核心判断：Go 里用 os.File 做读写操作时，context 的超时或取消信号是“发不进去”的。这不是 bug，而是底层抽象层级决定的天然结果。很多新手在这里栽跟头，以为把 context 传进 goroutine 就万事大吉，结果程序该卡死还是卡死。今天就把这个坑彻底聊透。

os.File.Read/Write 为什么无视 context.Done()

根源很简单：os.File 的 Read 和 Write 是纯同步系统调用，它既不接收 context.Context 参数，也不会主动检查 ctx.Done()。哪怕你传了一个带超时的 context 进 goroutine，Read 调用依然会老老实实卡在内核态，等着磁盘把数据吐出来——直到操作完成、出错、或者被信号中断。而 Go 运行时的默认策略是不发信号的。所以，context 的取消信号对它来说就像空气，完全不存在。这其实是设计上的有意解耦：I/O 操作和上下文控制层，本来就是两码事。

io.CopyContext 是最简可行方案（Go 1.19+）

如果你只是想做个文件复制、或者文件到 pipe 的流式传输，官方其实给了个现成工具：io.CopyContext（Go 1.19 引入）。它比 io.Copy 多了一个 context 参数，每次 Read 之后都会主动检查 ctx.Err()。一旦上下文取消或超时，它会立刻返回 context.Canceled 或 context.DeadlineExceeded，干净利落。

• 适用范围：只支持 io.Reader → io.Writer 的标准场景，不支持 ReadAt/WriteAt 或 mmap。
• 缓冲区由内部控制（默认 32KB），无需手动指定大小。
• 性能损耗极低，处理 GB 级文件时几乎可以忽略不计。
• 错误判断时务必用 errors.Is(err, context.Canceled)，别图省事直接用 == 比较，那样容易漏掉包装过的错误。

ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()

n, err := io.CopyContext(dst, src)
if err != nil {
    if errors.Is(err, context.DeadlineExceeded) {
        log.Printf("复制超时，已写入 %d 字节", n)
    }
    return err
}

需要 ReadAt/自定义缓冲/进度上报？自己分块 + select

标准方案总有不够用的时候。比如你需要从特定偏移量读取、要实时上报进度、或者想精确控制内存占用，那就只能手动实现分块循环了。核心思路很简单：在每次迭代前，通过 select 监听 ctx.Done()。

• 缓冲区大小建议在 64KB 到 1MB 之间。太小了系统调用开销大，太大了容易 OOM。
• 必须把 Read 调用放在 select 的 default 分支里，否则取消信号可能被饿死，永远轮不到它。
• 每次 Read 之前先 select 检查，这是个好习惯，能避免刚进入阻塞就被取消却无法响应。
• 注意处理部分读取：如果 Read 返回了 n > 0 但 err == nil，说明有数据可用，千万别直接丢掉。

buf := make([]byte, 64*1024)
for {
    select {
    case <-ctx.Done():
        return ctx.Err()
    default:
    }
    n, err := src.Read(buf)
    if n > 0 {
        // 处理 buf[:n]
        if _, werr := dst.Write(buf[:n]); werr != nil {
            return werr
        }
    }
    if err == io.EOF {
        break
    }
    if err != nil {
        return err
    }
}

别踩这些坑

常见误操作比想象中更隐蔽，而且后果很严重：

• 误操作一：把整个 io.Copy 包进 select 的 case 里。这没用，因为 io.Copy 内部根本不检查 context，它该卡还是卡。
• 误操作二：在 Read 调用前忘了写 select。这会导致 goroutine 卡死在系统调用上，cancel 永远不生效。
• 误操作三：试图用 os.File 配合 SetReadDeadline 来解决问题。这招只对网络文件系统（NFS）或某些特殊设备有效，本地 ext4/xfs 根本不支持。
• 误操作四：封装自定义 Reader 时，在 Read 开头就检查 ctx.Err() 并直接返回。这样做会跳过可能存在的缓冲数据或部分读取状态，导致数据丢失。

最后总结一句：真正关键的不是“有没有传 context”，而是“在哪一刻检查它”。必须在阻塞点之前检查，而且不能绕过可能存在的有效数据。搞明白了这一点，Go 的文件 I/O 上下文控制就算真正掌握了。