必须用libflac解析flac元数据，因其为链式二进制区块结构（如streaminfo、vorbis_comment），c++标准库无法识别语义；推荐使用flac__metadata_simple_iterator轻量读取，避免解码开销。
用 libflac 的 FLAC__metadata_get_tags() 读取 FLAC 元数据
FLAC 原生支持 Vorbis Comments（即常规音频标签，如 artist、title），但不支持 ID3。直接调用 libFLAC 的元数据接口最可靠，无需额外依赖或格式转换。
关键点：必须在解码前获取元数据，且需启用元数据遍历；FLAC__stream_decoder_new() 创建的解码器默认不加载元数据，要显式设置回调并启动遍历。
- 调用
FLAC__stream_decoder_set_metadata_respond_all()启用所有元数据块响应 - 实现
metadata_callback函数，只处理FLAC__METADATA_TYPE_VORBIS_COMMENT类型 - 在回调中遍历
block->data.vorbis_comment.comments，每个FLAC__StreamMetadata_VorbisComment_Entry的entry字段是"KEY=VALUE"格式的 C 字符串 - 注意：
entry不以\0结尾，长度由length字段给出，需手动复制并补\0
解析 Vorbis Comment 时常见的编码与内存陷阱
FLAC 规范要求 Vorbis Comments 使用 UTF-8 编码，但实际文件中可能出现非法字节序列或 Latin-1 混入。libFLAC 不做校验，直接暴露原始字节。
- 不要用
std::string(entry)直接构造——entry可能含 \0，且长度非 strlen - 正确做法：
std::string tag(reinterpret_cast<const char>(entry), length)</const> - 若需转为宽字符（如 Windows API），先用
std::mbrtoc16或第三方库（如 utf8cpp）验证并转换，避免崩溃 - 元数据回调中的
block指针仅在回调函数内有效，不可保存或跨线程使用
跳过解码只读元数据：用 FLAC__metadata_simple_iterator
如果只需要标签，完全不需要解码音频数据，FLAC__metadata_simple_iterator 更轻量、更快，且不依赖流解码器状态。
- 调用
FLAC__metadata_simple_iterator_new()→init()→ 循环next() - 对每个 block 判断
type == FLAC__METADATA_TYPE_VORBIS_COMMENT，再按前述方式解析 entry - 注意：
init()失败可能因文件路径含中文（Windows 下需用FLAC__metadata_simple_iterator_new_with_filename()配合 UTF-8 路径，或改用宽字符 API 封装） - 该迭代器不支持管道或内存 buffer 输入，只能读磁盘文件
为什么不用 TagLib？它对 FLAC 支持不稳定
TagLib 确实封装了 FLAC，但它内部仍调用 libFLAC，且版本滞后、错误处理粗糙。常见问题包括：
-
FileRef构造失败却不报具体原因（实际可能是 metadata block 损坏，而 libFLAC 会返回FLAC__METADATA_SIMPLE_ITERATOR_STATUS_READ_ERROR） - 对多值字段（如多个
GENRE）只返回最后一个，丢失数据 - 在 macOS 上静态链接时易出现符号冲突（TagLib 和直接链接的 libFLAC 版本不一致）
- 若项目已依赖 libFLAC，绕过 TagLib 可减少二进制体积和 ABI 风险
真正难的不是读取，而是容错：遇到损坏的 comment 块、超长 entry、空 key 或非 UTF-8 字节时，别让整个解析流程 abort——得逐字段校验长度、检查 = 分隔符位置、跳过非法 entry。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
