Arrow C++ 库需源码构建并显式启用关键组件（如-DARROW_PARQUET=ON）、使用cmake 3.15+、内置Thrift、合并chunks、对齐内存分配、正确处理Parquet逻辑类型、统一内存池及谨慎管理shared_ptr生命周期。
Arrow C++ 库怎么装才不踩 cmake 版本和依赖的坑
Arrow C++ 不是 apt install 一下就能用的，官方推荐从源码构建，但默认 cmake 配置会默默跳过很多关键组件（比如 IPC、JSON、Parquet），导致后续 arrow::ipc::RecordBatchFileReader 直接链接失败或运行时崩溃。
- 必须显式开启
-DARROW_PARQUET=ON、-DARROW_IPC=ON、-DARROW_JSON=ON，否则看似编译成功，但一用序列化就报undefined reference to arrow::ipc::ReadRecordBatch - cmake 3.15+ 是硬门槛，Ubuntu 20.04 自带的 3.16 可以，但 CentOS 7 默认的 2.8 会静默忽略新选项，最终生成一个“功能残缺”的库
- 别用系统级
libthrift：Arrow 内置了 thrift 子模块，若系统已装旧版 thrift（如 0.9.3），cmake 可能误连，引发std::bad_cast在arrow::ipc::ReadRecordBatch中炸开；建议加-DARROW_THRIFT_SOURCE=internal
如何正确创建并写入一个 Arrow Table 到内存缓冲区
很多人以为 arrow::Table::FromRecordBatches 返回的对象可以直接序列化，其实它只是逻辑容器，底层数据没做内存对齐和字节序处理，直接传给 arrow::ipc::SerializeRecordBatch 会出错。
- 必须先用
arrow::Table::CombineChunks合并碎片化 chunk，否则 IPC writer 可能写入无效 offset - 写入前务必调用
arrow::ipc::GetRecordBatchSize预估缓冲区大小，再用arrow::AllocateBuffer分配对齐内存（Arrow 要求 64 字节对齐） - 实际写入要用
arrow::ipc::IpcWriteOptions::Defaults()，别用空构造——默认选项里use_threads=false和max_recursion_depth=64是保底安全值，改高了在嵌套 schema 下容易栈溢出
示例关键片段：
auto options = arrow::ipc::IpcWriteOptions::Defaults(); int64_t size = 0; arrow::ipc::GetRecordBatchSize(*batch, &size); std::shared_ptr<arrow::Buffer> buffer; arrow::AllocateBuffer(size, &buffer); arrow::io::BufferOutputStream stream(buffer); arrow::ipc::SerializeRecordBatch(*batch, options, &stream);
读取 Parquet 文件时 schema 不匹配的典型表现和修复方式
用 arrow::dataset::ScanOptions 读 Parquet，常遇到字段名存在但 arrow::Array::length() 返回 0，或者 arrow::Cast 失败报 NotImplemented: No cast implemented from int64 to timestamp[ms] —— 这不是数据坏了，而是 Parquet 的 logical type 和 Arrow 的物理 type 映射没对上。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- Parquet 里
timestamp_ms逻辑类型，在 Arrow 中对应arrow::timestamp(arrow::TimeUnit::MILLI)，不是arrow::int64()；必须用arrow::dataset::ParquetFragment::Read时传入显式arrow::dataset::ParquetFileFormat::default_read_options()，否则 logical type 被忽略 - 如果原始 Parquet 是用 Python pandas 写的，它默认把 string 写成
UTF8logical type，但 Arrow C++ 读出来可能是arrow::binary()；此时需在arrow::dataset::ScanOptions::use_threads = false下手动arrow::compute::Cast到arrow::utf8() - 字段缺失时，
arrow::dataset::ScanOptions::use_threads=true可能导致部分 batch 丢列；关掉线程最稳
为什么 shared_ptr<arrow::Table> 传参后突然 segfault
Arrow 对象重度依赖引用计数，但它的 shared_ptr 不是“普通”智能指针：底层 arrow::MemoryPool 默认绑定到当前线程，跨线程传递 shared_ptr<arrow::Table> 后，若在另一线程调用 table->ToStructArray()，可能触发 pool 释放时访问已销毁的 TLS 变量。
立即学习“C++免费学习笔记（深入）”；
- 所有 Arrow 对象跨线程使用前，必须统一指定非默认 pool：
arrow::default_memory_pool()或自定义全局池，不能依赖线程局部池 - 避免在 lambda 捕获中隐式拷贝
shared_ptr<arrow::Schema>后又调用schema->field(i)->type()—— 如果该 field 类型是arrow::dictionary()，而 dictionary array 尚未加载，会触发延迟初始化，此时若原始shared_ptr<arrow::Table>已析构，就崩 - 调试时加
ARROW_LOG_LEVEL=3环境变量，能看到 pool 分配/释放轨迹，比 gdb 单步更快定位悬挂引用
最易被忽略的一点：Arrow 的 arrow::Table::Slice 返回的是视图，不增加底层 array 引用计数；如果只保存 slice 而丢弃原 table，array 内存可能提前释放——得用 arrow::Table::CombineChunks 或显式 arrow::Array::Slice 才安全。
