Go io.LimitReader 怎样保留错误信息

在 Go 里给文件、请求体或消息流设置读取上限时，io.LimitReader 通常是最顺手的入口。它不会把底层 Reader 的非 EOF 错误改成“读取成功”：错误仍会沿着 Read 返回值传回。真正容易误判的是，读取达到上限后同样会看到 io.EOF，这个 EOF 只能说明限制器没有更多数据可交给调用方，不一定说明源数据自然结束。

因此，保留错误信息的关键是同时接住数据和错误，并在需要判断截断时额外记录限制状态。下面按实际工程里的几个取舍展开。

先回答：LimitReader 会不会吞掉底层错误

不会。官方实现把 io.LimitReader(r, n) 构造成一个 *io.LimitedReader。它先检查剩余字节数，再缩短传给底层 Reader 的缓冲区；底层返回多少字节，限制器就扣减多少，底层返回的错误也会继续返回。只有剩余字节已经小于等于零时，限制器才直接返回 io.EOF。

调用方不要只看错误而丢掉本次已经读到的字节。Reader 合约允许一次调用同时返回 n > 0 和非空错误，所以应先处理 data[:n]，再根据错误决定是否结束。

package main

import (
	"errors"
	"fmt"
	"io"
)

var errBrokenStream = errors.New("底层流中断")

type brokenReader struct {
	data []byte
	done bool
}

func (r *brokenReader) Read(p []byte) (int, error) {
	if len(r.data) > 0 {
		n := copy(p, r.data)
		r.data = r.data[n:]
		if len(r.data) == 0 && !r.done {
			// 模拟一次 Read 同时交付最后一段数据和底层错误。
			r.done = true
			return n, errBrokenStream
		}
		return n, nil
	}
	return 0, io.EOF
}

func readPrefix(src io.Reader, limit int64) ([]byte, error) {
	// LimitReader 只限制读取范围，不负责把错误变成业务语义。
	data, err := io.ReadAll(io.LimitReader(src, limit))
	if err != nil {
		// %w 保留原始错误，调用方仍可使用 errors.Is 判断它。
		return data, fmt.Errorf("读取消息前缀: %w", err)
	}
	return data, nil
}

func main() {
	data, err := readPrefix(&brokenReader{data: []byte("header")}, 16)
	if err != nil {
		fmt.Println("保留的错误:", errors.Is(err, errBrokenStream))
	}
	fmt.Println("已读取字节:", len(data))
}

io.ReadAll 会把已经收到的数据和错误一起交给调用方；外层用 %w 包装后，错误文本增加了上下文，但错误身份没有丢。这个模式比把所有错误都替换成一个“读取失败”字符串更适合上层重试、统计和告警。

达到上限时，EOF 到底代表什么

官方 LimitedReader.Read 的边界很直接：N 时返回 0, io.EOF。所以当你写出下面的代码时，err == nil 只代表 io.ReadAll 没收到非 EOF 错误，不代表源数据一定短于上限。

func readWithState(src io.Reader, limit int64) ([]byte, bool, error) {
	limited := &io.LimitedReader{R: src, N: limit}
	data, err := io.ReadAll(limited)
	if err != nil {
		// 非 EOF 错误仍然返回，data 可能包含错误发生前的内容。
		return data, false, err
	}
	// N 为 0 只能说明限制器已经用完额度；若源数据刚好等于 limit，
	// 这里无法仅靠 EOF 判断它是否还有后续内容。
	return data, limited.N == 0, nil
}

这个 hitLimit 更准确地说是“限制额度已用完”，而不是百分之百的“源数据被截断”。如果业务必须确定源数据是否超过上限，可以故意多读一个字节，再把它从结果中裁掉：

func readAndDetectOverflow(src io.Reader, limit int64) ([]byte, bool, error) {
	if limit  limit {
		return data[:limit], true, nil
	}
	return data, false, nil
}

“多读一个字节”会改变流的消费位置，因此只适用于调用方允许预读、或后续本来就不会继续使用同一个 Reader 的场景。对网络请求体、压缩流等共享输入，不能为了一个状态标记随意探测。

错误要加上下文，但不要抹掉原始类型

如果限制读取属于更大的业务动作，例如“读取配置头”或“读取上传文件的前缀”，建议在边界处加上下文：

func loadHeader(src io.Reader) ([]byte, error) {
	data, err := io.ReadAll(io.LimitReader(src, 4096))
	if err != nil {
		// %w 让 errors.Is / errors.As 继续沿错误链工作。
		return data, fmt.Errorf("读取配置头: %w", err)
	}
	return data, nil
}

不要把 io.EOF、底层连接错误和文件权限错误都格式化成同一个普通字符串。上层通常需要用 errors.Is 判断可预期的结束，用 errors.As 取出更具体的错误类型。对于 io.ReadAll，正常 EOF 通常不会作为失败返回；真正的底层非 EOF 错误才会到达这里。

按负载选择读取方式

云上或服务端代码里，我通常按“是否需要完整内容”和“是否还要继续消费源 Reader”做选择：

可以把结论压缩成三句话：LimitReader 会保留底层非 EOF 错误；EOF 可能来自读取上限；需要原始错误身份时用 %w，需要确认溢出时再评估“多读一个字节”的成本。

常见问题

io.LimitReader 会返回“超过上限”的错误吗？

不会。它的职责是把可读范围限制为最多 N 字节，触顶后返回 EOF。如果业务需要“超限”这个语义，应由调用方通过独立状态或多读一个字节来判断。

为什么读取到 EOF 后还要关心 data？

Reader 可以在同一次 Read 中返回已读取的字节和错误。正确写法应先处理有效的 n 个字节，再决定是否结束，不能因为 err 非空就直接丢弃这批数据。