Go io.LimitReader 怎么限制上传读取量

在 Go 上传接口里，io.LimitReader 能限制“最多从 Reader 读多少字节”，但它不会自动把请求判定为超大并返回 HTTP 错误。读到上限后，它把后续内容表现为 io.EOF。如果目标是保护 HTTP 请求体，通常应在解析之前使用 http.MaxBytesReader，让超限请求进入可识别的错误分支。

一、先分清 LimitReader 能限制什么

io.LimitReader 接收一个 io.Reader 和 int64 上限，返回另一个 Reader。内部的 *io.LimitedReader 每次读取都会扣减剩余字节数；当额度变成 0 时，下一次读取返回 io.EOF。这对读取文件头、生成预览或限制一次性内存占用很有用。

关键误区是把 EOF 当成“上传被拒绝”。它只说明这个受限 Reader 没有更多可交付的数据，不能告诉你原始请求体后面是否还有第 n+1 个字节。因此下面的代码会得到最多 4 MiB 的数据，但不会因为原始内容更大而自动报错：

const previewLimit int64 = 4 

二、上传接口要把读取边界和拒绝策略分开

真正的上传接口需要的是“超过上限就失败”，而不是安静地保存半个文件。标准库提供的 http.MaxBytesReader 正是面向请求体的包装器：它返回可关闭的 Reader，超过限制读取时会返回 *http.MaxBytesError，并在可能时提示服务器关闭连接。

限制要放在 ParseMultipartForm、json.Decoder.Decode 或任何 io.Copy 之前。一个最小 Handler 可以这样写：

const maxUploadBytes int64 = 10 

示例里的 10 MiB 只是策略示例，不是所有业务的正确值。头像、CSV 导入和视频分片应分别设定上限；同时还要给反向代理配置相容的请求大小限制，避免请求在不同层得到不同结果。

三、只需要读取前 N 个字节时再使用 LimitReader

如果场景只是读取文件头判断格式、生成文本摘要或给下游库提供一个有界 Reader，io.LimitReader 仍然是合适的选择。它不拥有底层资源，不能替代 Close；当原始 Reader 是 r.Body、文件或压缩流时，关闭责任仍由外层代码承担。

如果业务必须判断“内容是否超过上限”，可以把读取额度设为 limit+1，读完后检查长度是否大于 limit。但对于 HTTP 请求体，直接使用 http.MaxBytesReader 更清晰，因为超限语义已经由标准库表达出来。

func readAtMost(src io.Reader, limit int64) ([]byte, bool, error) {
	// 多读一个字节，只用于判断源数据是否超过业务上限。
	buf, err := io.ReadAll(io.LimitReader(src, limit+1))
	if err != nil {
		return nil, false, err
	}
	return buf[:min(len(buf), int(limit))], int64(len(buf)) > limit, nil
}

四、部署前检查这几个容易漏掉的边界

第一，限制要早于任何会消费 Body 的操作；第二，完整读取成功前不要创建最终文件或写入数据库；第三，所有打开的 Body、临时文件和 multipart 资源都要按责任关闭。Content-Length 可以帮助提前拒绝一部分请求，但不能代替读取时的限制，因为请求可能使用分块传输，或长度头本身不可信。

相关问题

io.LimitReader 会自动关闭底层文件吗？

不会。它返回的是 Reader，不接管底层资源的关闭责任；打开文件或请求体的代码仍应负责调用 Close。

读到 LimitReader 的 EOF 是否说明上传刚好结束？

不一定。EOF 可能只是达到人为设置的上限；要判断是否超限，需要多读一个字节，或改用 http.MaxBytesReader。

MaxBytesReader 应该放在 ParseMultipartForm 前吗？

应该。先包裹 r.Body，再解析 multipart、JSON 或表单，才能让后续读取都处在同一个请求体上限内。