Go go-wav PCMBuffer与FullPCMBuffer有什么区别

同一份 WAV 文件，调用 FullPCMBuffer() 和 PCMBuffer() 得到的都是 PCM 样本，但它们解决的是两种不同的问题：前者负责“一次性拿到全部数据”，后者负责“由调用方决定每次拿多少”。如果线上出现内存上涨、首次处理延迟变长，通常不是 WAV 格式突然变了，而是把全量读取误用在了需要分批消费的场景。

官方地址：https://pkg.go.dev/github.com/go-audio/wav

需要整段样本并且数据规模可控时选 FullPCMBuffer；需要持续处理、限制内存或处理长音频时选 PCMBuffer。最重要的差别是内存生命周期和读取节奏，而不是返回的数据类型。

先看症状：同一个 WAV，两个方法为什么会走出不同结果

一次音频任务里，我们先把问题拆成三个现象：调用 FullPCMBuffer() 时要等到整个 PCM 数据读完；内存峰值随着音频时长增长；改成 PCMBuffer() 后，每次只处理一个固定大小的样本块。go-audio/wav 的文档也把 FullPCMBuffer 描述为低效率的全量访问方式，并建议考虑 PCMBuffer()。

触发条件：FullPCMBuffer 为什么容易把内存问题放大

WAV 的样本规模大致由采样率、声道数、位深和时长共同决定。FullPCMBuffer 会从 PCM chunk 逐个解码，并把样本追加到 audio.IntBuffer.Data；源代码还会按块扩展底层切片，最后再裁剪到实际长度。这个过程方便，但它的峰值与整段音频相关。

下面的示例适合“小文件、全量算法”场景。代码中的注释解释了资源关闭和错误路径；它不是分批读取方案。

package main

import (
    "fmt"
    "os"

    "github.com/go-audio/wav"
)

func loadAll(path string) error {
    f, err := os.Open(path)
    if err != nil {
        return fmt.Errorf("open wav: %w", err)
    }
    defer f.Close() // 文件句柄由当前函数负责释放。

    d := wav.NewDecoder(f)
    buf, err := d.FullPCMBuffer()
    if err != nil {
        return fmt.Errorf("decode full pcm: %w", err)
    }
    fmt.Printf("samples=%d channels=%d\\n", len(buf.Data), buf.Format.NumChannels)
    return nil
}

如果这段代码运行在上传接口或批处理服务里，多个请求同时进入时，每个请求都可能保留一整段 Data。这就是“单个文件看起来没问题，叠加并发后内存突然吃紧”的触发条件。

修复动作：把全量读取改成固定批次循环

PCMBuffer(buf) 的关键是传入一个已经分配好 Data 的 audio.IntBuffer。缓冲区长度决定本次最多读取多少个样本；方法返回 n，表示本次真正填充的数量。最后一个批次可能不足整个缓冲区，所以业务只处理 buf.Data[:n]。

package main

import (
    "fmt"
    "io"
    "os"

    "github.com/go-audio/audio"
    "github.com/go-audio/wav"
)

func processInBatches(path string) error {
    f, err := os.Open(path)
    if err != nil {
        return fmt.Errorf("open wav: %w", err)
    }
    defer f.Close() // 解码完成后关闭底层读取器。

    d := wav.NewDecoder(f)
    buf := &audio.IntBuffer{Data: make([]int, 2048)} // 固定本次内存预算。

    for {
        n, err := d.PCMBuffer(buf)
        if err != nil && err != io.EOF {
            return fmt.Errorf("read pcm batch: %w", err)
        }
        if n == 0 {
            break // 没有有效样本，循环结束。
        }

        batch := buf.Data[:n]
        fmt.Printf("process %d samples\\n", len(batch))
        // 在这里完成特征提取、编码或写入下游队列。
    }
    return nil
}

这里的核心不是把 2048 当成固定答案，而是把“缓冲区长度”变成可调参数：CPU 更关注吞吐时可以适当增大，内存更紧张或需要更细粒度延迟时可以减小。无论怎么调，都要按 n 截取有效样本，不能直接把整个 buf.Data 当作本次输出。

防复发：用这张清单决定选哪个方法

1. 算法必须看到完整波形，例如整段统计、全局归一化或一次性重采样，而且音频长度受控：选择 FullPCMBuffer()，并把并发数和文件大小纳入内存预算。
2. 任务可以边读边处理，例如分块编码、实时特征提取或写入消息队列：选择 PCMBuffer()，让固定缓冲区复用。
3. 同一个 Decoder 的 PCM 游标已经向后移动时，不要假定第二次调用会自动从头开始；需要重复解码时，先按库提供的 Rewind() 语义重新定位，再开始下一轮。

一句话总结：FullPCMBuffer 优先简化代码，代价是全量内存；PCMBuffer 优先控制资源，代价是你需要编写循环和尾批处理。把选择放在“数据规模、处理算法、并发模型”三个条件上，通常就不会再把两者当成同义 API。

常见问题

PCMBuffer 返回的 n 为什么可能小于缓冲区长度？

因为文件剩余样本不足一个完整批次，最后一次只会填充实际读到的数量。后续处理应使用 buf.Data[:n]。

FullPCMBuffer 是否代表音频文件的字节数？

不是。返回的是解码后的 audio.IntBuffer，Data 的元素是样本值；声道、采样率和源位深保存在缓冲区格式信息中。