应使用 arrow/go 库（github.com/apache/arrow-go/v14）操作 Arrow 内存数据，严格遵循 C Data Interface 和 IPC 标准；禁止手动构造内存结构，须通过 array.NewXXXData 创建数组并显式 Release；Schema 需显式声明 nullability；RecordBatch 所有数组必须共享同一 memory.Allocator；IPC 序列化需按需配置 version 与 compression；timestamp 单位须与 schema 中 TimestampType.Unit 严格一致。
Go 里用 arrow/go 库读写 Arrow 内存数据，不是靠自己实现格式
Arrow 内存布局是跨语言统一的二进制规范（Columnar layout + IPC metadata），Go 没有、也不该从零手撸内存结构。实际做法是依赖官方维护的 arrow/go 库（即 github.com/apache/arrow-go/v14），它已严格对齐 Arrow C Data Interface 和 IPC 标准。直接操作 C.DataBuffer 或手动拼 schema header 属于高危行为，容易触发段错误或跨语言不兼容。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference —— 多因跳过 array.NewInt64Data 等构造函数，直接 new struct 并未初始化 buffer 字段；或未调用 defer arr.Release() 导致内存泄漏后 buffer 被提前回收。
- 必须通过
array.NewXXXData（如array.NewInt64Data）或array.FromSlice创建数组，它们会自动分配并绑定内存 buffer - 所有
array.Array和memory.Allocator实例需显式.Release()，否则 Go GC 不感知 Arrow 堆外内存 - Schema 定义必须用
arrow.Field显式声明 nullability，nullable: false和nullable: true在 IPC 序列化时生成完全不同的 buffer 结构
构建 RecordBatch 时，buffer 对齐和内存 allocator 必须一致
Arrow 要求所有 column buffer 在内存中按 64-byte 对齐，且同一 RecordBatch 内所有数组必须共享同一个 memory.Allocator 实例。混用默认 allocator 和自定义 allocator（比如用 memory.NewGoAllocator()）会导致 batch.Err() != nil，但错误信息模糊（常为 "invalid buffer length"）。
使用场景：高频小 batch 合并（如流式聚合）时，复用 allocator 可避免频繁 mmap；离线批处理则建议用 memory.NewCheckedAllocator(memory.DefaultAllocator) 捕获越界写。
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 创建 batch 前先定义 allocator：
alloc := memory.NewGoAllocator() - 每个 array 构造时传入该 allocator：
array.NewInt64Data(array.WithData(...), array.WithAllocator(alloc)) - 最终用
array.NewRecord组装时，所有 arrays 必须来自同一 alloc，否则record.Schema().Fields()可能 panic
序列化为 IPC 格式（如 Arrow File）要显式指定 writer version 和 compression
arrow/go 默认序列化为 Arrow 1.0 IPC 格式，但若下游系统（如 DuckDB、Polars）要求 Arrow 14+ 的 dictionary encoding 优化或 LZ4_FRAME 压缩，则必须手动配置 ipc.WriterOption。忽略此步会导致文件可读但性能差，或被新版本 reader 拒绝（报错 "unsupported ipc format version"）。
参数差异：ipc.WithVersion(ipc.V5) 仅启用字典编码，而 ipc.WithCompression(ipc.CompressionLZ4) 需配合 ipc.WithVersion(ipc.V5) 才生效；V4 及以下版本不支持压缩。
- 写 Arrow File：
w := ipc.NewFileWriter(f, schema, ipc.WithVersion(ipc.V5), ipc.WithCompression(ipc.CompressionLZ4)) - 写 Stream（如 gRPC payload）：
w := ipc.NewStreamWriter(f, schema, ipc.WithVersion(ipc.V5))—— Stream 不支持压缩 - 读取时无需指定 version，库自动识别，但 compression 必须匹配，否则
reader.Record()返回nil且无明确错误提示
与 C/C++ 或 Python（pyarrow）交互时，注意 Go 的 int64 和 Arrow 的 timestamp 单位不一致
Go 的 time.Time.UnixMilli() 返回毫秒，但 Arrow timestamp type 默认单位是微秒（arrow.Millisecond vs arrow.Microsecond）。若 schema 中定义为 arrow.FixedWidthTypes.Timestamp_us，却用 time.Unix(0, ms*1e6) 构造时间戳，会导致值偏移 1000 倍 —— Python 侧 pa.array(...).to_pandas() 显示为公元 1970 年之后 1000 年。
性能影响：timestamp 单位错配不会 crash，但数值全错，且无法通过 schema 检查发现（因为类型名一样，只是 unit 字段不同）。
- 定义 schema 时显式指定 unit：
arrow.Field{Name: "ts", Type: &arrow.TimestampType{Unit: arrow.Microsecond}} - 构造数组时用对应精度转换：
us := t.UnixMicro()（Go 1.19+），再传入array.NewTimestamp128Data(..., us) - 若必须兼容毫秒单位，改用
arrow.Millisecond并用t.UnixMilli()，但需确保上下游全部同步修改
最容易被忽略的是：Arrow 的 timestamp type 在 Go 中没有自动 time.Time 转换，所有时间戳都只是 int64，unit 完全由 schema 中的 TimestampType.Unit 决定，和 Go 的 time 包无关。
