aiff文件头必须手动构造，因标准库不支持；需严格按form-aiff-comm-ssnd顺序写入108字节头部，满足chunk对齐、big-endian字节序及采样率ieee 80-bit浮点等要求。
AIFF 文件头必须手动构造，标准库不提供封装
AIFF 是 Apple 定义的无压缩 PCM 音频格式，本质是 IFF（Interchange File Format）容器。C++ 标准库和 STL 完全不支持 AIFF 封装，fwrite 或 std::ofstream::write 只能写裸 PCM 数据——但裸数据不是 AIFF，缺少 108 字节固定头部 + 可选注释块 + chunk 对齐要求，直接双击打不开，ffprobe 会报 Invalid data found when processing input。
关键点在于：AIFF 要求所有 chunk 大小为偶数字节（padding 到 2 字节边界），且 COMM 和 SSND chunk 必须按顺序、严格字节对齐写入。漏掉 padding 或顺序错乱，多数播放器静音或崩溃。
实操建议：
- 用
uint8_t数组手写 108 字节 header：前 4 字节为"FORM"，接着 4 字节是总文件大小（需预留并最后回填），再 4 字节"AIFF"，然后"COMM"chunk（18 字节，含声道数、采样点数、位深、采样率 IEEE 754 float） -
SSNDchunk 前必须写 8 字节 chunk header（"SSND"+ 4 字节 chunk size），chunk size = 实际 PCM 字节数 + 8（因 SSND 自带 8 字节 offset/blockSize 字段） - PCM 数据写入前，确保样本按 AIFF 要求的字节序：big-endian（例如 16-bit 样本需用
htons()转换） - 写完全部数据后，seek 回文件开头，填入最终文件大小（总长 − 8，因为 FORM size 不含自身 8 字节）
采样数据类型与 AIFF 位深必须显式匹配
AIFF 不存储“类型信息”，只存 raw bytes + COMM chunk 中声明的 sampleSize（单位 bit）和 numChannels。若你有 int32_t 线性采样数据，但 COMM 声明 sampleSize = 16，播放器会每 2 字节截一个样本，结果完全失真；反之，声明 32 但传入 16-bit 数据，会读越界或解包失败。
常见组合与处理方式：
- 16-bit PCM → 写入前用
static_cast<int16_t></int16_t>截断，并用htons()转 big-endian - 24-bit PCM → 必须填充为 3 字节对齐（AIFF 允许 24-bit，但需在 COMM 中设
sampleSize = 24，写入时按 3 字节/样本打包，高位在前） - 32-bit float → AIFF 支持，但需在 COMM 中设
sampleSize = 32，且写入前用htonl()+ 逐字节 reinterpret_cast→ uint32_t（注意 float 的 IEEE 754 表示本身是大端依赖，x86 需字节翻转） - 非整数倍位宽（如 20-bit）不可直接存 AIFF，必须 dither 后降为 16 或升为 24
流式导出必须缓冲并延迟写 header，避免内存暴涨
真实场景中，音频数据可能来自实时采集或解码器输出，无法预知总采样数。若等全部数据收完再写 header，就得把所有 PCM 缓存在内存里——1 分钟 48kHz/24-bit 立体声 ≈ 276 MB，极易 OOM。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
可行做法是分块流式写入，但 header 必须最后修正：
- 先写死一个占位 header（108 字节全 0），记录当前 file offset
- 循环接收
std::vector<int16_t></int16_t>或float*数据块，转换、字节序翻转后直接write()到文件 - 每块写入后更新累计 PCM 字节数，用于后续计算
SSNDsize 和总文件大小 - 全部数据写完，
seekp(4)跳到 FORM size 字段，填入file_size - 8；再seekp(18)（COMM chunk 起始）更新采样总数字段（COMM 中第 10–13 字节） - 务必调用
flush()并检查good()，否则最后一块可能滞留在 buffer 里
用 libaiff 或 sndfile 替代手写？权衡点在这里
有人会说：“干嘛不用 libsndfile？”——它确实支持 AIFF 写入，API 简洁：sf_writef_short() 一行搞定。但它引入动态链接依赖，且对流式场景不友好：内部仍会缓存整个 COMM+SSND 结构，写入首块前就要知道总长度（除非用 SF_INFO.frames = -1 模式，但部分版本有 bug）。
libaiff 更轻量，但维护停滞（最新 commit 在 2018），不支持 24-bit 写入，且默认不处理字节序转换。
所以进阶选择其实是：小项目/学习用 libsndfile 快速验证；高可控性、嵌入式或低延迟流式导出，坚持手写 header + ofstream，把 padding、endian、chunk order 这三处逻辑封成一个 AiffWriter 类，复用时只关心 write_samples(const void*, size_t) 接口。
最容易被忽略的是：AIFF 的采样率字段是 10-byte IEEE 80-bit extended precision float（不是 double），手写时必须用特定打包函数（如 Apple 提供的 double_to_ieee_extended() 变体），否则 QuickTime 或 Logic Pro 会拒绝识别——这点连很多开源库都处理错误。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
