Go x/image/riff RIFF 块长度为什么不总等于下个块偏移

先说结论：RIFF 的块长度字段只表示当前块的数据区长度，不包含 8 字节块头，也不包含奇数长度数据后的 1 个对齐字节。因此，下一个块的物理偏移不是简单的“当前偏移 + chunkLen”，而是：

下一个块偏移 = 当前块头偏移 + 8 + chunkLen + (chunkLen & 1)

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

这也是 Go 的 golang.org/x/image/riff 能够连续读取块的原因：Reader.Next 会在读取下一个块前排空旧数据，并在需要时消费 padding byte。手动定位或自己写 RIFF 解析器时如果忘记这一步，奇数长度块之后就会把填充字节误认为下一个块的 ID。

先把 RIFF 块的物理布局拆开

官方文档把一个 RIFF chunk 描述为 8 字节头部、数据区和 padding bytes。头部前 4 字节是 FourCC，后 4 字节是小端序的长度字段。这个长度字段对应 chunkData 可读出的数据字节数，而不是从当前块头到下一个块头的总距离。

例如，当前块头从偏移 100 开始，chunkLen=4 时，下一个块从 100+8+4=112 开始；chunkLen=5 时，数据区结束在 113，但为了保持下一个头部对齐，还要跳过 1 个 padding byte，下一个块从 114 开始。

chunkLen 为什么不是下一个块的偏移量

长度字段只回答“这个块的数据有多少字节”。偏移量还必须回答“从哪里开始计算”以及“中间是否存在不属于数据区的字节”。可以把定位公式拆成三段：

• 8：当前块自己的 ID 和长度字段。
• chunkLen：当前块真正交给调用方读取的数据。
• chunkLen & 1：数据长度为奇数时追加的对齐字节，否则为 0。

这个规则只影响物理游标，不会改变返回值中的 chunkLen。因此，读取一个 5 字节块时，调用方应该读取 5 个数据字节；第 6 个字节是格式对齐，不应混入业务数据。

另一个容易混淆的字段是 LIST 的长度。NewReader 先读出 RIFF 头和 form type，然后把剩余长度交给内部 Reader；NewListReader 对 LIST 也会先消费 4 字节 list type，再把剩余长度作为子块范围。外层长度、LIST 长度和单个 chunkLen 是不同层级，不能互相替代。

Reader.Next 如何处理上一个块的尾部

riff.Reader.Next 的设计把“读块数据”和“移动到下一个块”拆成了两个时机。第一次调用返回块头和一个 io.Reader；下一次调用 Next 时，Reader 会先排空上一个数据 reader 剩余的字节，再根据上一个长度是否为奇数读取 padding byte，最后才读取下一个 8 字节头部。

package main

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

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

func main() {
    // RIFF 数据通常来自文件；这里用字符串构造一个最小的内存输入。
    form, chunks, err := riff.NewReader(strings.NewReader(data))
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println("form:", form)

    for {
        id, length, body, err := chunks.Next()
        if err == io.EOF {
            break
        }
        if err != nil {
            log.Fatal(err)
        }

        // 只读取 length 个数据字节；奇数长度后的 pad 由下一次 Next 处理。
        payload, err := io.ReadAll(body)
        if err != nil {
            log.Fatal(err)
        }
        fmt.Printf("%s length=%d payload=%d\\n", id, length, len(payload))
    }
}

const data = "RIFF" + "\\x1e\\x00\\x00\\x00" + "WAVE" +
    "ODD1" + "\\x05\\x00\\x00\\x00" + "abcde" + "\\x00" +
    "EVEN" + "\\x04\\x00\\x00\\x00" + "wxyz"

上面的输入中，第一个子块声明 5 字节数据，后面紧跟一个填充字节；第二个子块的头部并不是紧接在第五个数据字节之后，而是在填充字节之后。代码没有手动读取 padding，因为这正是 Next 的职责。

不要在 Next 之后继续使用旧的 chunkData

官方 API 明确说明：返回的 io.Reader 会在下一次调用 Next 后变成 stale reader。最稳妥的写法是，在进入下一轮之前把当前块需要的数据读完，或者把它复制到自己的缓冲区；不要保存返回的 reader，等后面再次使用。

func readChunk(r *riff.Reader) error {
    id, length, body, err := r.Next()
    if err != nil {
        return err
    }

    // 这里一次性读完当前 chunk，避免下一次 Next 后 reader 失效。
    payload, err := io.ReadAll(body)
    if err != nil {
        return err
    }
    if uint32(len(payload)) != length {
        // 读到的数据不足时，保留块 ID 方便上层定位损坏位置。
        return fmt.Errorf("chunk %s: got %d, want %d", id, len(payload), length)
    }
    return nil
}

Next 即使上一个数据 reader 没有被完全读取，也会尝试排空剩余内容；但这不表示可以长期持有旧 reader。把它读完后再进入下一次调用，生命周期更清晰，也更容易把短数据错误归因到具体块。

遇到偏移错乱时按这四项排查

1. 确认长度字段是小端序。 RIFF 的 4 字节长度不是字符串数字，也不是大端整数。
2. 确认公式包含 8 字节头。 只把 chunkLen 加到当前偏移，会把下一个块头提前 8 字节。
3. 确认奇数长度多跳过 1 字节。 这个字节属于格式对齐，不属于 chunkData。
4. 确认边界错误的层级。 errShortChunkHeader 说明头部不完整，errShortChunkData 说明数据不足，缺少奇数长度填充时则可能得到 errMissingPaddingByte。

如果你自己通过 Seek 定位，使用上面的物理偏移公式；如果通过 riff.Reader 顺序读取，让 Next 管理填充和 LIST 边界，调用方只处理实际的 chunkData。

几个容易混淆的问题

chunkLen 是不是包含 8 字节块头？

不是。它只描述数据区，块头和 padding 都不计入这个字段。

所有 RIFF 块后面都有 padding byte 吗？

不是。只有数据长度为奇数时才需要 1 个对齐字节；偶数长度块没有额外填充。

可以直接把 chunkLen 加到文件偏移上吗？

不能。至少要加上当前块的 8 字节头；如果长度为奇数，还要再加 1 个 padding byte。

为什么读完 chunkData 后还要由 Next 处理一次？

因为 padding 是容器格式的对齐信息，不属于当前数据 reader。Next 在切换块时统一处理，调用方就不会把它误当成业务数据。

总结一下：RIFF 的长度字段和物理偏移描述的是两件事。chunkLen 只管数据区，实际下一个块的位置还要加 8 字节头和可能存在的 1 个 padding byte。使用 golang.org/x/image/riff 时按块读完数据、在下一次 Next 后不再使用旧 reader；手动解析时则把对齐规则明确写进偏移计算。