Go io限制上传读取长度的安全写法

上传接口最怕的不是文件大，而是读取边界没有真正落到代码里。只检查请求头里的 Content-Length 不够可靠，直接调用 io.ReadAll 又会把整个输入放进内存。更稳妥的写法是：用 io.LimitReader 把读取窗口设为“允许大小 + 1 字节”，再用 io.Copy 流式写入临时目标；复制后超过上限就删除临时文件，只有在边界内才提交。

官方文档：https://pkg.go.dev/io

先把读取上限变成明确的字节边界

假设业务允许的最大文件是 10 MiB，真正需要传给读取器的不是 10 MiB，而是 10 MiB 加 1。这样，读到第 10 MiB 时仍可接受；如果还能读到第 10 MiB 加 1 个字节，就能明确判断输入超限。io.LimitReader 返回一个最多读取指定字节数的 Reader，包装后不会因为源流很大而一次性分配同等大小的内存。

这里的“加一”是探测位，不是允许保存的额外内容。写入临时文件后，应用仍要用原始上限判断结果。

流式复制后要区分成功、超限和读取失败

下面的函数只接收一个 io.Reader 和临时文件路径，适合放在 HTTP 框架之外的业务层。它不把输入整体读入内存，并把临时文件作为未提交状态处理。

package upload

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

func SaveLimited(src io.Reader, tempPath string, maxBytes int64) error {
    // 上限必须为正，避免零值配置变成误删或无意义的上传入口。
    if maxBytes >1) {
        return errors.New("upload size limit is too large")
    }
    limited := io.LimitReader(src, maxBytes+1)
    dst, err := os.Create(tempPath)
    if err != nil {
        return fmt.Errorf("create temp file: %w", err)
    }
    // 任何失败路径都不留下半成品，成功时再由上层提交临时文件。
    cleanup := true
    defer func() {
        _ = dst.Close()
        if cleanup {
            _ = os.Remove(tempPath)
        }
    }()

    written, err := io.Copy(dst, limited)
    if err != nil {
        return fmt.Errorf("read upload: %w", err)
    }
    if written > maxBytes {
        return fmt.Errorf("upload exceeds %d bytes", maxBytes)
    }
    if err := dst.Close(); err != nil {
        return fmt.Errorf("close temp file: %w", err)
    }
    cleanup = false
    return nil
}

示例中的返回值只表示临时文件已经通过字节上限，正式路径还应执行原子改名、对象存储提交或数据库记录。关闭文件失败也不能被忽略，否则提交动作可能早于底层写入真正完成。

LimitReader、CopyN 和请求头应该怎么选

如果接口还要校验 MIME、扩展名或压缩包内容，字节上限只是第一层边界。读取完成后再做类型判断，并把临时文件放在不对外暴露的目录；超限、解析失败和存储失败都应清理未提交文件。

常见问题

为什么不直接使用 io.CopyN？

io.CopyN 更适合“必须复制满 n 字节”的协议或定长记录。上传场景既要接受小于上限的文件，又要发现上限之外是否还有内容，用 LimitReader(maxBytes+1) 再检查实际字节数更直观。

读到刚好 maxBytes 算超限吗？

不算。只有探测窗口读到了第 maxBytes+1 个字节，才说明实际内容超过配置上限。

限制读取后还需要检查 Content-Length 吗？

需要，但它只适合做早期拒绝和节省连接资源。最终边界仍应由受限 Reader 和复制结果共同决定。