libogg本身不解析音频内容，只负责拆页（page）；要解码ogg里的音频，必须搭配libvorbis（或libopus）一起用。单独链libogg无法读出pcm，因其仅处理ogg容器结构（读页头、校验crc、切分数据块），不识别流类型，也不解码vorbis/opus等编码数据。
直接说结论：libogg 本身不解析音频内容，只负责拆页（page）；要解码 OGG 里的音频，必须搭配 libvorbis（或 libopus）一起用。单独链 libogg 是读不出 PCM 的。
为什么只连 libogg 会卡在“无法识别流类型”
OGG 是容器，不是编码器。libogg 只做三件事：读页头、校验 CRC、按页切分数据块。它完全不关心页里是 Vorbis、Opus 还是 Theora —— 这些由上层解码库判断。
常见错误现象：ov_open() 返回 -1，ov_info() 崩溃，或 ov_read() 持续返回 0。
根本原因：你传给 ov_open() 的 FILE* 或自定义 I/O 函数没正确喂数据，或者没链接 libvorbis 导致符号缺失（尤其 Windows 下容易漏 vorbisfile.lib）。
- 必须确保
#include <vorbis></vorbis>，而非仅<ogg></ogg> - 链接顺序不能错：
libvorbisfile→libvorbis→libogg（反向会报 undefined reference） - Windows 下若用静态库，需定义
VORBISFILE_STATIC宏，否则ov_open_callbacks可能调用失败
ov_open_callbacks 自定义 I/O 的坑点
当音频数据来自内存（如资源包、网络缓存），不能直接用 fopen，得靠 ov_open_callbacks。但它的回调函数签名和行为极易出错：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
read_func必须返回实际读取字节数，不能硬返回size1 * size2；返回 0 表示 EOF，负值表示错误 -
seek_func中SEEK_END的偏移量是从文件末尾算起，不是从 0 开始，写成ptr + fileSize + to就越界 -
close_func若返回非 0，ov_clear()可能跳过清理，导致句柄泄漏 - 回调结构体（如
ogg_file）生命周期必须覆盖整个OggVorbis_File生命周期，不能栈分配后就返回
多音轨/串流 OGG 的采样率与通道数陷阱
ov_info(&vf, -1) 返回的是逻辑流（logical bitstream）的主信息，但 OGG 支持单文件内多个独立流（比如左声道一个流、右声道一个流）。如果文件含多流，ov_info(..., -1) 取的是第一个流，而实际解码时 ov_read() 可能混入其他流的数据，导致 PCM 长度错乱或播放杂音。
- 务必检查
ov_streams(&vf)返回流数量，大于 1 时需用ov_info(&vf, stream_no)显式遍历每个流 - Vorbis 流的
sampleRate和channels不一定全等；混合流中常见 44.1kHz + 48kHz 共存，强行统一会重采样失真 -
ov_pcm_total(&vf, -1)在多流下返回总样本数，但ov_pcm_tell(&vf)只反映当前流位置，二者不可直接换算
真正麻烦的从来不是怎么打开 OGG，而是确认你拿到的 PCM 数据属于哪个流、有没有被截断、字节序是否匹配 OpenAL 或 SDL 所需格式 —— 这些细节在 libogg 层面根本看不到，得靠 libvorbisfile 的状态机和手动校验。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
