Go malgo 怎样在结束播放时释放设备和上下文

Go malgo 结束播放时，核心不是把几个释放函数随意堆在一起，而是按资源所有权收口：设备由 Device.Uninit() 处理，设备都不再活跃后再调用 Context.Uninit()，如果上下文来自 InitContext()，最后再调用 AllocatedContext.Free()。Device.Stop() 只是让设备休眠，适合暂停后还要继续播放的场景，不是完整的设备销毁接口。

官方地址：https://pkg.go.dev/github.com/gen2brain/malgo

一个播放会话的清理边界可以记成：先结束 Device，再结束 Context，最后释放 AllocatedContext；不要让仍活跃的设备进入 Context.Uninit。

先分清设备与上下文的生命周期

malgo 是 miniaudio 的 Go 绑定。创建上下文后，程序可以把同一个 Context 交给一个或多个设备；设备又持有数据回调、停止回调和底层音频后端的关联。这个层次决定了清理责任：设备级资源归 Device.Uninit()，上下文级资源归 Context.Uninit()，由 InitContext() 创建的封装对象还要由 Free() 收尾。

因此，结束播放前先列出当前会话实际创建过的对象。只创建了一个设备，就只需要收口这个设备；如果一个上下文管理多个设备，要等这些设备都完成反初始化后再处理上下文。这个判断比“程序退出了所以一起释放”更可靠。

把清理顺序写进 defer 结构

正常播放路径可以让设备初始化成功后立即登记清理责任。下面的代码是结构示例，展示接口职责和错误分支；音频数据本身由回调产生，示例没有把任何输出描述成真实运行结果。

package main

import (
    "fmt"

    "github.com/gen2brain/malgo"
)

func playSession() (err error) {
    // InitContext 返回的封装对象拥有上下文资源，函数结束时负责 Free。
    ctx, err := malgo.InitContext(nil, malgo.ContextConfig{}, nil)
    if err != nil {
        return fmt.Errorf("init audio context: %w", err)
    }
    defer ctx.Free()

    deviceConfig := malgo.DefaultDeviceConfig(malgo.Playback)
    deviceConfig.SampleRate = 48000
    device, err := malgo.InitDevice(ctx.Context, deviceConfig, malgo.DeviceCallbacks{
        // 回调只负责填充播放缓冲，不在这里释放 Device 或 Context。
        Data: func(_, output []byte, _ uint32) { clear(output) },
    })
    if err != nil {
        return fmt.Errorf("init playback device: %w", err)
    }
    // Uninit 会显式停止设备；重复调用 Stop 不是清理前提。
    defer device.Uninit()

    if err := device.Start(); err != nil {
        return fmt.Errorf("start playback device: %w", err)
    }

    // 这里代表播放结束或收到退出信号，返回后执行设备和上下文清理。
    return nil
}

这段写法把“创建成功就登记清理”作为原则：上下文成功后登记 Free()，设备成功后登记 Uninit()。Go 的 defer 按后进先出执行，所以设备清理会先于上下文清理，正好满足 malgo 对活跃设备的约束。设备初始化失败时，设备没有创建成功，不会误调用设备方法；上下文仍会由已经登记的 Free() 收口。

暂停、销毁与上下文释放不是同一件事

Device.Stop() 的语义是让设备休眠，之后还可以再次调用 Start()。如果只是播放暂停，可以保留设备和上下文，不必销毁它们；如果播放会话彻底结束，Device.Uninit() 才是设备反初始化入口。官方说明还指出，Uninit() 自己会显式停止设备，因此不需要把 Stop() 当作必经前置步骤。

Context.Uninit() 的约束更严格：当这个上下文创建的任何设备仍然活跃时调用，结果未定义。多设备场景不能只看主播放设备，要把录音设备、全双工设备和临时预览设备一起纳入会话清单。若设备对象被封装在其他结构中，清理函数应由拥有它的结构统一负责，避免调用方遗漏。

几个容易把资源边界写错的场景

把 Stop 当成释放。Stop 只改变设备运行状态，设备及回调关联仍在。暂停后继续播放可用 Stop；会话结束则应让 Uninit 承担设备收尾。

先 Uninit 上下文。上下文不是设备的替代品。必须先确保该上下文下的设备不再活跃，再处理 Context.Uninit；若用了 AllocatedContext，最后还要 Free。

初始化失败仍执行设备清理。只有拿到非 nil 的 Device 后才登记 defer device.Uninit()。把 defer 写在 InitDevice 之前，会让错误路径变成空指针风险。

在数据回调里释放对象。数据回调属于设备运行期间的工作边界，不适合直接销毁设备或上下文。退出信号应回到拥有播放会话的控制函数，由那里完成统一收口。

用一张表确认最后的清理契约

可以把最终规则压缩为一句话：暂停用 Stop，结束用 Device.Uninit，所有设备结束后用 Context.Uninit，最后释放 AllocatedContext。当播放、录音和预览共享一个上下文时，把这些清理责任放在会话拥有者里，资源边界会比散落在回调和调用方中的写法更清楚。

Device.Uninit 前必须手动调用 Stop 吗？

不必须。malgo 文档说明 Uninit 会显式停止设备；如果业务先调用 Stop 再 Uninit 也可以，但 Stop 不是设备销毁的必要步骤。

Context.Uninit 返回错误要不要忽略？

不建议无条件忽略。它返回 error，调用方可以记录或向上返回；尤其在多设备场景，错误提示有助于发现仍存在未收口的设备或后端问题。

为什么用 defer ctx.Free 还要关心 Context.Uninit？

Free 负责释放由 InitContext 分配的封装数据，并不替代 Context.Uninit 的上下文反初始化职责。两者属于不同资源层级，应该按设备、上下文、封装对象分别收口。

技术依据：malgo 官方 Go 包文档。正文代码、结构说明图和清理表为本文原创。