Go go-wav 编码器Close为何需要可定位输出

用 Go 的 github.com/go-audio/wav 编码 PCM 时，Encoder.Close 不是普通的“结束调用”。它必须回到文件头，把 RIFF 总长度和 data 块长度写回去，所以 NewEncoder 的输出参数要求是 io.WriteSeeker。如果传入的对象只能写不能定位，编码流程就没有办法把先前写入的占位长度改成最终值。

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

最稳妥的顺序是：创建可定位的 *os.File → Write 写入 PCM → 检查 Encoder.Close → 再关闭底层文件。Encoder.Close 不负责关闭底层 writer。

Close 为什么必须能定位输出

WAV 文件头在开始写入时还不知道最终数据量。go-audio/wav 会先写入临时长度，记录 PCM 数据块长度所在的位置；随后 Close 使用 Seek 回到偏移 4 的 RIFF 长度字段，再回到 PCM 块长度字段，写入最终值，最后跳回文件尾。这样播放器或解码器读取头部时，看到的长度才和实际采样数据一致。

这也解释了为什么 bytes.Buffer 不能直接作为参数：它实现了 io.Writer，但没有 Seek。即使前面的 PCM 字节已经写进内存，Close 仍无法完成头部修正。

用 os.File 完成一次可靠编码

文件输出是最简单的方案，因为 *os.File 同时满足写入和定位。下面的示例生成单声道、16 位、44100Hz 的 PCM 文件。示例中的采样数据只用于演示编码契约，重点是资源关闭顺序。

package main

import (
    "fmt"
    "os"

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

func encodeWAV(path string, samples []int) error {
    // 文件需要支持 Seek，Close 才能回写 WAV 头部长度。
    out, err := os.Create(path)
    if err != nil {
        return fmt.Errorf("创建 WAV 文件失败: %w", err)
    }
    defer out.Close() // Encoder.Close 不会代替底层文件 Close。

    enc := wav.NewEncoder(out, 44100, 16, 1, 1)
    buf := &audio.IntBuffer{
        Format: &audio.Format{SampleRate: 44100, NumChannels: 1},
        Data:   samples,
    }
    if err := enc.Write(buf); err != nil {
        return fmt.Errorf("写入 PCM 失败: %w", err)
    }
    // Close 会 Seek 回头部修正 RIFF 和 data 的长度，必须检查错误。
    if err := enc.Close(); err != nil {
        _ = os.Remove(path) // 头部未修正时不要留下半成品。
        return fmt.Errorf("完成 WAV 头部失败: %w", err)
    }
    return nil
}

func main() {
    // 这里给出一个短的 PCM 样本，真实项目可替换成采集或解码结果。
    if err := encodeWAV("tone.wav", []int{0, 1200, 2400, 1200, 0, -1200, -2400, -1200}); err != nil {
        panic(err)
    }
}

调用顺序不要倒过来。先执行 out.Close() 会让后续 Encoder.Close 的定位和写入失败；而只调用 enc.Close() 又不会释放文件描述符。生产代码还应根据业务决定是否在关闭失败时删除目标文件或改名为临时文件。

输出目标怎么选：文件、内存还是管道

选择输出方式时，关键不是“能不能写”，而是“最终长度是否需要回头修改”。如果最终交付是 WAV 文件，优先直接写可定位文件；如果接口只接受内存字节，可以先写临时文件，关闭编码器后再读取文件内容；如果是网络管道或实时流，则不适合直接使用这个需要回写头部的编码器，应换用支持流式封装的方案，或先缓冲完整内容。

不要通过把类型强行转换成接口来绕过这个边界。io.WriteSeeker 是能力要求，不是形式要求；缺少定位就无法保证头部里的长度可信。

几个容易忽略的关闭边界

• 空编码器：Close 对空 receiver 或空 writer 会直接返回，不代表已经生成了有效 WAV。
• 位深限制：Write 的 PCM 缓冲会按 8、16、24、32 位分支编码，其他位深应在进入编码器前处理。
• 写入错误：不要只检查 Write；头部回写、Seek 或文件同步也可能在 Close 时报错。
• 大文件：RIFF 与 PCM 长度字段是 32 位无符号值，超大音频需要确认格式容量和业务切片方案。

常见问题

只调用 Write 不调用 Close 会怎样？

文件可能有 PCM 字节，但长度字段仍是占位值，播放器或解码器可能把它判为不完整或读取时长异常。

Encoder.Close 会关闭 os.File 吗？

不会。它只刷新内容、修正头部，并在底层对象是 *os.File 时调用同步；文件仍应由调用方关闭。

为什么不能把 HTTP 响应 writer 直接传进去？

HTTP writer 通常不提供回头定位，响应头一旦发出也无法修改 WAV 的前置长度。应先缓冲完整文件，或使用适合实时传输的封装格式。