Go bufio.Reader.WriteTo 写入失败时怎样保留复制错误

用 bufio.Reader 把剩余数据复制到另一个 io.Writer 时，WriteTo 返回的两个值都不能丢：n 表示已经复制的字节数，err 表示复制是否因为输入或输出问题停止。目标 Writer 可能已经写入一部分内容后才报错，所以只看错误类型会丢掉恢复所需的进度。

官方地址：https://pkg.go.dev/bufio#Reader.WriteTo

Reader.WriteTo 的正确处理方式是把 n 和 err 作为一个结果保存：err == nil 才代表本次复制正常结束；n > 0 且 err != nil 则代表已经产生部分输出，是否重试必须由业务决定。

先看 WriteTo 返回什么

WriteTo 实现了 io.WriterTo，签名是 WriteTo(w io.Writer) (n int64, err error)。它可能多次读取底层 Reader；如果底层 Reader 自己实现了 WriteTo，还可能直接调用底层方法而不经过当前缓冲层。

用可失败 Writer 还原现象

为了理解为什么要保留两个返回值，可以准备一个达到写入上限后返回错误的 Writer。这个 Writer 不是生产组件，只用于说明目标端已经接收部分数据时，复制操作不会把进度自动还原。

package main

import (
    "bufio"
    "errors"
    "fmt"
    "io"
    "strings"
)

type limitedWriter struct {
    remain int64
    cause  error
}

func (w *limitedWriter) Write(p []byte) (int, error) {
    if w.remain == 0 {
        // 目标已经达到容量上限，后续写入直接返回原始错误。
        return 0, w.cause
    }
    count := int64(len(p))
    if count > w.remain {
        count = w.remain
    }
    w.remain -= count
    if count 

这里的重点是 n 和 err 的组合：当 Writer 已经接收若干字节后返回错误，WriteTo 的调用方仍然能够知道已经产生了多少输出。若目标是文件、网络连接或消息缓冲区，是否能从这个位置继续，取决于目标端是否支持定位、幂等写入或断点协议。

按 n 和 err 处理三种结果

实际代码可以先保存结果，再按错误来源做分支。不要把所有非空错误都包装成“没有写入”，也不要把 n > 0 自动当成成功。对于输出端的错误，通常需要保留目标标识、已复制字节数和原始错误；对于输入端的错误，则应记录源读取位置和是否允许重新读取。

func copyReader(reader *bufio.Reader, dst io.Writer) error {
    n, err := reader.WriteTo(dst)
    if err == nil {
        // 只有无错误返回，才把本次复制标记为完整完成。
        fmt.Printf("复制完成，字节数=%d\n", n)
        return nil
    }

    // 保留 n 与 err，便于日志、重试策略或断点记录使用。
    return fmt.Errorf("WriteTo 在 %d 字节处停止: %w", n, err)
}

如果底层 Writer 违反 io.Writer 约定，返回的字节数小于输入切片长度却不给出非空错误，相关复制工具可能补成 io.ErrShortWrite。调用方不应依赖“短写但无错”作为正常路径，而应该把实现不合约视为需要修复的 Writer 问题。

检查缓冲和底层 Reader 的边界

WriteTo 不等同于简单地循环调用当前 bufio.Reader.Read。官方文档明确说明：它可能多次读取底层 Reader；如果底层 Reader 支持 WriteTo，当前方法会在不经过缓冲的情况下调用它。因此，给 Reader 包装额外的观测逻辑时，要确认实际被调用的是哪一层。

另外，WriteTo 不被视为一次普通的读操作。若代码依赖 UnreadByte 的“回退最近一次读取”语义，不要在 WriteTo 之后继续假设上一个字节仍然可以按普通读取路径回退。复制前应先完成需要窥探、回退或记录位置的操作。

func copyOnce(reader *bufio.Reader, dst io.Writer) (int64, error) {
    // WriteTo 会消费 Reader 中剩余的数据，调用前先确认这是预期行为。
    n, err := reader.WriteTo(dst)
    if err != nil {
        // 失败时返回进度与原始错误，让上层决定是否能安全重试。
        return n, err
    }
    // 成功后 Reader 已经没有本次复制范围内的剩余数据。
    return n, nil
}

用速查表收束实现

可以把这条规则记成一句话：WriteTo 成功与否看 err，恢复进度看 n。两者必须一起写入日志或结果对象，目标端是否幂等、是否可定位，再由具体存储或传输协议决定。

相关问题

WriteTo 返回 n > 0 就算成功吗？ 不算。只有 err == nil 才表示这次复制正常结束，n 只说明已经复制了多少字节。

目标 Writer 返回短写时应该忽略吗？ 不应该。按 io.Writer 约定，短写应伴随非空错误；否则就是 Writer 实现不符合约定，调用方应保留异常上下文。

WriteTo 失败后能不能直接再次调用？ 不能一概而论。Reader 可能已经消费了部分输入，只有在目标支持幂等、输入可重新打开或协议能按偏移恢复时才适合重试。