Go x/image/riff 容器声明长度大于实际输入怎么办

Go x/image/riff 容器声明长度大于实际输入时，应把它作为未完整接收或结构不一致的输入返回错误。不要把缺失部分补零，也不要只因 NewReader 成功就保存成功结果。对于已完整接收的字节数组，可以先比较 RIFF 头部长度与实际字节数，再逐块读取、核对块数据长度，并一直处理 Next 的错误直到容器正常结束。

官方地址：https://pkg.go.dev/golang.org/x/image/riff

把声明长度当作待满足的约定

RIFF 起始部分含四字节标识和小端长度字段；该长度描述长度字段之后的容器内容，包含四字节 form type。因此，完整容器总字节数应按 uint64(声明值)+8 计算，不能把声明值直接当成文件总长度。

这里讨论的是接收与解析契约，没有某个新版本才修复这一问题的前提。一个典型场景是上传端已经写出声明大小，连接却在负载传完之前结束。另一个可能来源是生成器没有在最终编码完成后正确回填长度。两者都需要保留错误，不能把声明值当成已经存在的字节。

为什么 NewReader 成功仍可能读到截断

NewReader 读取容器起始信息并建立后续块读取器，并不提前读取全部容器。实际输入是否能满足长度，要在读取后续块头、块数据及对齐字节时才能暴露。按当前官方源码，短容器头、短块头、短数据及缺少填充可能对应不同错误。

另一个容易漏掉的细节是，块数据 Reader 遇到底层 EOF 时，调用方读取函数可能只得到“少量字节加正常结束”。因此，主动读完块后，还应把读到的字节数与 chunkLen 比较。不能只看 io.Copy 是否返回 nil，更不能把所有 EOF 都一律转为成功。相关行为可从 RIFF 官方实现追溯。

RIFF 的块长度不包含八字节块头，奇数字节块还涉及对齐填充。文件包含所有业务数据，并不自动说明容器尾部的对齐也完整。读取完最后一块仍要调用 Next，让容器级结束和填充处理真正发生。

为单容器内存输入增加完整接收约束

下面函数约定 raw 是已经完整取得、只允许包含一个 RIFF 容器的内存输入。它限制整体输入大小、拒绝尾随字节，扫描顶层块并核对负载长度。这个严格单容器策略由应用选择，不是声称 RIFF 所有使用场景都必须拒绝尾随数据。示例未运行，不提供虚构成功输出。

package riffinput

import (
    "bytes"
    "encoding/binary"
    "fmt"
    "io"

    "golang.org/x/image/riff"
)

// InspectOne 只检查顶层容器完整性，不解码具体媒体内容。
func InspectOne(raw []byte, maxInput int) (riff.FourCC, int, error) {
    var zero riff.FourCC
    if maxInput  maxInput {
        return zero, 0, fmt.Errorf("输入额度不满足要求")
    }
    if len(raw)  actual {
        return zero, 0, fmt.Errorf("容器截断: 声明 %d 字节，实际 %d 字节", declared, actual)
    }
    if declared != actual {
        return zero, 0, fmt.Errorf("单容器输入含尾随字节")
    }

    form, r, err := riff.NewReader(bytes.NewReader(raw))
    if err != nil {
        return zero, 0, fmt.Errorf("读取容器头: %w", err)
    }
    count := 0
    for {
        id, size, data, err := r.Next()
        if err == io.EOF {
            return form, count, nil
        }
        if err != nil {
            return zero, 0, fmt.Errorf("读取块头或对齐数据: %w", err)
        }
        // 不按不可信的声明长度分配负载数组，仅流式计数。
        n, err := io.Copy(io.Discard, data)
        if err != nil {
            return zero, 0, fmt.Errorf("读取块 %q: %w", id, err)
        }
        if n != int64(size) {
            return zero, 0, fmt.Errorf("块 %q 数据不足: %w", id, io.ErrUnexpectedEOF)
        }
        count++
    }
}

该函数的完整接收比较不适合直接套在尚未结束的网络流上。实时流没有最终实际长度时，可以先按接收协议和应用额度完成暂存，或持续读取受限容器并传播错误；接收超时、连接关闭和容器解析结果需要分别保留。不要把 Content-Length 与 RIFF 内部长度混为一谈，前者属于传输消息约定。

代码把 LIST 当作顶层负载读取，没有递归解释内部子块，也没有判断 WAVE、AVI 或 WebP 的特定语义。完整顶层容器并不代表媒体一定能解码。输入额度只约束本函数接收的 raw；上传端需要在创建这个数组之前控制接收资源。

把旧代码的成功条件改到读取完成后

我会让解析函数在失败时返回不可提交的结果，而不是一边解析一边把阶段性信息登记为最终资源。需要容错预览时，可以单独设计“部分可读”状态，但不能把它冒充完整媒体。解析过程中拿到的 chunkData 也应在下一次 Next 前使用完，避免保存失效 Reader。

排查上传与编码端的长度来源

先确认错误发生在上传、落盘还是再次读取阶段，并记录实际接收数、容器声明总数和块标识等结构信息。排查时使用保留的原始样本，对照编码器回填逻辑和传输中断记录；不要直接修改用户原始数据来掩盖错误。长度正确但子块越过父容器剩余额度，属于另一种结构不一致，同样应返回失败。

声明长度过大一定是网络问题吗？不一定，也可能是文件生成器写错长度、文件被截取或接收后读取范围有误。错误只证明输入未满足结构约定，不能单凭它判断来源。

只靠 io.LimitReader 就能保证完整吗？不能。它约束最多读取多少，不保证底层能提供那么多；仍需检查实际读到的数量和解析错误。

能通过修改头部长度修复吗？不建议在通用接收链路自动这么做。缺失的媒体数据无法靠更改数字恢复，受控修复工具也必须了解具体媒体结构，并保留原始输入。