Go x/image/riff Next 怎样遍历容器块

用 Go 遍历 RIFF 容器时，不需要自己解析每个 8 字节块头。golang.org/x/image/riff 已经把块头、块长度、奇数字节填充和读取边界封装进 Reader.Next。常用做法是先用 NewReader 取得顶层类型，再循环调用 Next；遇到 LIST 块时交给 NewListReader 创建子读取器。

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

最小可靠模式是：NewReader 负责顶层 RIFF，Next 负责当前层的块，io.EOF 表示当前层结束，LIST 再打开一个新的 *riff.Reader。每次调用下一次 Next 前，应完成当前 chunkData 的读取。

先看清 riff.Reader 的职责

RIFF 流由一串 chunk 组成。每个 chunk 有 4 字节的 FourCC 类型、4 字节长度、对应数据和必要的填充字节。riff.FourCC 是长度为 4 的字节数组，适合表达 RIFF、LIST、WAVE 等固定标识。

NewReader 返回两个核心结果：顶层 form type 和当前层的 *riff.Reader。它不负责把所有数据读进内存，因此遍历大容器时可以让调用方决定哪些块需要读取、哪些块只需跳过。

用 Next 逐块取出三个返回值

Next 每次返回 chunkID、chunkLen 和 chunkData。真正需要内容时再读取 chunkData，这样可以避免为了识别块类型而提前分配整块缓冲区。

package main

import (
    "fmt"
    "io"
    "log"
    "strings"

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

func dumpLevel(r *riff.Reader, indent string) error {
    for {
        chunkID, chunkLen, chunkData, err := r.Next()
        if err == io.EOF {
            // 当前层没有更多块，属于正常结束，不应当当成损坏输入。
            return nil
        }
        if err != nil {
            // 非 EOF 错误表示读取器无法继续解释当前容器。
            return fmt.Errorf("读取 RIFF 块失败: %w", err)
        }

        fmt.Printf("%s%s length=%d\\n", indent, chunkID, chunkLen)
        if chunkID == riff.LIST {
            // LIST 的数据首部包含 list type，交给库创建嵌套读取器。
            listType, child, err := riff.NewListReader(chunkLen, chunkData)
            if err != nil {
                return fmt.Errorf("读取 LIST 类型 %s 失败: %w", chunkID, err)
            }
            fmt.Printf("%sLIST type=%s\\n", indent, listType)
            if err := dumpLevel(child, indent+"  "); err != nil {
                return err
            }
            continue
        }

        // 只有确实需要块内容时才读取，避免无意义的内存增长。
        payload, err := io.ReadAll(chunkData)
        if err != nil {
            return fmt.Errorf("读取块 %s 内容失败: %w", chunkID, err)
        }
        fmt.Printf("%sdata=%q\\n", indent, payload)
    }
}

func main() {
    // 示例只演示调用关系；实际项目应把文件或网络流传入 NewReader。
    formType, r, err := riff.NewReader(strings.NewReader("..."))
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("form=%s\\n", formType)
    if err := dumpLevel(r, ""); err != nil {
        log.Fatal(err)
    }
}

上面的 strings.NewReader("...") 只是占位输入，不能当作一个完整 RIFF 文件。实际使用时应传入文件、网络响应体或其他实现了 io.Reader 的数据源。关键分支是先判断 io.EOF，再处理其他错误。

LIST 块怎样打开下一层容器

LIST 不是普通业务 payload。它的块数据前部包含 list type，后面仍然是一组 RIFF 块。拿到 riff.LIST 后，调用 NewListReader(chunkLen, chunkData)，得到 listType 与新的 *riff.Reader，然后复用同一个遍历函数即可。

这种设计把“当前层的块读取”和“嵌套层的块读取”分开：父级只管理是否进入 LIST，子级 Reader 管理自己的块边界。不要把 chunkData 强行转换成完整字节切片后再手工切块，否则容易重复处理长度和对齐规则。

chunkData 的生命周期要按当前层处理

官方文档特别说明：返回的 io.Reader 会在下一次调用 Next 后失效。因此有两种安全策略：

• 当前块内容不大：在下一次 Next 前用 io.ReadAll 或固定上限的读取方式消费它。
• 当前块需要交给下游：在当前调用周期内完成下游处理，不把这个 reader 存到下一轮循环或异步任务中。

这条规则不等于必须读取每一个块。对于只关心元数据的程序，可以依据 chunkID 直接跳过内容，然后继续下一次 Next；但要记住，跳过动作也必须发生在下一次 Next 之前，避免把父级和当前块的边界交给业务代码重复处理。

结束条件与错误处理怎么区分

当前层没有更多 chunk 时，Next 返回 io.EOF。递归函数应把它转换成当前层的正常返回；如果读取到格式错误、截断或其他 I/O 错误，则原样保留上下文并向上传递。

写 RIFF 遍历器时的取舍

如果目标是列出容器结构，递归遍历比把整个文件读成 []byte 更合适：它保留了 Reader 的流式边界，也能在发现目标块后提前结束。只有需要随机访问、重复解析同一块或后续 API 明确要求字节切片时，才把当前块复制到独立缓冲区。

另外，chunkLen 是无符号长度，显示时可以直接打印，但在转成具体分配大小前仍要结合业务上限。对外部文件不要因为长度字段看起来合理就无界 io.ReadAll；可以使用带上限的读取器，并把超限当成业务错误处理。

func readLimited(data io.Reader, limit int64) ([]byte, error) {
    // 多读一个字节，用来判断内容是否超过业务上限。
    limited := io.LimitReader(data, limit+1)
    payload, err := io.ReadAll(limited)
    if err != nil {
        return nil, fmt.Errorf("读取块数据失败: %w", err)
    }
    if int64(len(payload)) > limit {
        // 超限时返回业务错误，避免继续持有过大的内存结果。
        return nil, fmt.Errorf("块数据超过 %d 字节上限", limit)
    }
    return payload, nil
}

常见问题

Next 返回 io.EOF 是文件损坏吗？

不一定。对当前层来说，io.EOF 表示已经没有更多块；只有在仍期待固定结构而提前结束时，才应结合上层语义判断是否异常。

为什么不能缓存 chunkData 到下一轮？

因为下一次 Next 后该 reader 会失效。需要异步处理时，应在当前块仍有效时复制出独立数据，并把复制后的数据交给异步任务。

LIST 一定要递归吗？

不一定。只需要统计顶层块时可以跳过 LIST；需要读取其中的子块时，再用 NewListReader 打开子层。递归的边界应由业务目标决定。

记住这条调用关系即可：NewReader → Reader.Next →（LIST 时）NewListReader → 子 Reader.Next。把每一层的 io.EOF 和当前块生命周期处理清楚，就能稳定遍历 RIFF、WAVE、AVI 或 WEBP 等使用该容器格式的内容。