Go x/image/riff Next 后旧块 Reader 为什么不能继续使用

riff.Reader.Next 返回的块数据 Reader 只对应当前块；再次调用 Next 后，旧 Reader 就失效，不能继续使用。它不是独立文件，也不是已经复制到内存的数据。需要延后处理时，应在下次 Next 之前读完并复制所需字节，或者先把当前块写入独立存储。

官方文档：https://pkg.go.dev/golang.org/x/image/riff

块 Reader 借用的是当前读取状态

RIFF 容器由块构成，每个块有类型、长度和数据，可能还有填充。Next 返回 chunkID、chunkLen、chunkData 和 error。chunkData 通过父 Reader 读取同一条底层流，所以保留一个 io.Reader 接口变量，并不会获得数据所有权。

官方实现中，块 Reader 关联父 Reader 的当前块状态。父级推进后，旧对象不再是当前块。问题不在于局部变量出了作用域，而在于其有效期已经结束。因此，换一个变量名、包一层结构体或把接口放进切片都无法延长它的有效期。

在下一次 Next 前复制需要的数据

下面函数把每个顶层块复制成自有字节切片后才推进。它同时限制单块数据、累计数据和块数量，避免“为了修复生命周期”而无条件读入所有内容。代码只展示容器读取，不声称已解码任何具体媒体文件，也没有虚构执行结果。

package riffcopy

import (
    "fmt"
    "io"
    "golang.org/x/image/riff"
)

type Chunk struct {
    ID riff.FourCC
    Data []byte
}

// Collect 复制顶层块；不递归解析 LIST，预算仅计算块数据。
func Collect(src io.Reader, maxChunk, maxTotal uint64, maxCount int) ([]Chunk, error) {
    if maxCount = maxCount || uint64(size) > maxChunk ||
            uint64(size) > maxTotal-used {
            return nil, fmt.Errorf("块数量或数据预算超限")
        }
        // 在下次 Next 之前完成复制，不保存借用的 data Reader。
        payload, err := io.ReadAll(data)
        if err != nil {
            return nil, fmt.Errorf("读取块 %q: %w", string(id[:]), err)
        }
        if uint64(len(payload)) != uint64(size) {
            return nil, fmt.Errorf("块 %q 数据长度不完整", string(id[:]))
        }
        used += uint64(len(payload))
        chunks = append(chunks, Chunk{ID: id, Data: payload})
    }
}

返回的 Data 是复制得到的字节，不再依赖当前块 Reader。若把这些数据交给其他工作单元，应明确只读或修改的所有权；不要同时修改同一切片。函数本身不关闭 src，资源关闭由创建它的调用方负责。

预算针对块负载，不包括 Go 对象、切片额外容量、头信息和输入读取耗时。声明长度通过检查也不代表内存一定足够，预算需由应用合理配置。对文件或网络来源，还应在入口采用适当的总输入与读取时间策略。

按资源预算选择处理方式

需要并发时，父级仍负责顺序推进，把已经复制的数据作为任务输入。直接将 chunkData 交给后台任务、主循环立刻继续 Next，会让两个使用方争用同一读取状态；即便偶尔看起来成功，也不符合接口有效期约定。

本文的风险重点是读取状态误用与资源失控，不把普通容器解析故障描述成已发生的攻击事件。采用哪种方案取决于负载与保留时长，不需要为了这个问题重建一套复杂服务。

保留错误与嵌套块的读取边界

文档允许当前块没有全部读完就调用 Next。实现会处理剩余数据并推进，但这并不是把旧块留给调用方以后再读。也不要把该行为理解为任意跳过都没有成本：底层流仍可能需要实际读取剩余部分，并且可能返回截断或填充错误。

io.EOF 作为 Next 的结束信号，与块数据不完整等其他错误需要区分。示例会继续调用 Next 直到正常结束，避免只处理某块后就把后续结构问题忽略。如果只读取部分容器，应在函数名与返回语义上明确这一范围。

遇到 LIST 块时，可以在当前块有效期内通过 NewListReader 解析其子块。子读取器依赖当前块数据，不能在父 Reader 已推进后才继续读取；若先复制 LIST 的字节，再用独立字节源解析，则有效期由那个副本管理。示例 Collect 只保留顶层负载，没有自动递归。

常见疑问与接入清单

旧 Reader 已经读到 EOF，还能再用吗？推进后仍应遵守失效约定，不要用重复读取旧对象作为正常业务流程。

加锁是否能让旧 Reader 长期有效？锁只能协调访问；父级已经推进后，加锁不会把旧块的数据恢复出来。需要独立副本或延迟推进。

Reader 返回了，底层文件就可以关闭吗？未复制时仍依赖底层资源。复制完成的数据才能在不依赖该文件的情况下处理。

接入时明确三件事：谁推进父读取器、何时复制数据、谁释放独立存储。让借用的 Reader 留在当前块处理范围内，通常就能消除这类生命周期误用。

参考：Next 接口约定、RIFF 官方实现。