grib_handle 必须手动调用 codes_handle_delete() 释放，否则循环读多报文会导致内存泄漏；获取数据前须先 codes_get_size() 再分配缓冲区并传 &size 给 codes_get_double_array()；网格类型需按 gridtype 分支处理，推荐用 codes_gribiterator；多线程须用 codes_open_file() 而非 fopen()。
grib_handle* 要手动释放，不释放会内存泄漏
用 eccodes 读 GRIB2 文件时，codes_handle_new_from_file() 每次都分配新内存，返回的 grib_handle* 必须配对调用 codes_handle_delete()。很多人只在单次解析时注意释放，但在循环读多个报文（比如一个文件含 100+ 个 GRIB 消息）时漏掉这步，进程 RSS 持续上涨，最后 OOM。
实操建议：
- 每个
codes_handle_new_from_file()后紧跟if (!h) { /* error */ }判断，再进处理逻辑 - 处理完立刻
codes_handle_delete(h)，别依赖作用域或延后统一释放 - 若用 C++ RAII 封装，析构函数里必须调
codes_handle_delete()，且指针置为nullptr - 不要把
grib_handle*存入容器长期持有——它不支持拷贝，也不带引用计数
获取数据值前必须先调 codes_get_size() 和 codes_get_double_array()
GRIB2 的数据段是压缩存储（如 JPEG2000、PNG、complex packing），codes_get_double_array() 内部会自动解压并转换为 double 数组。但如果你跳过前置检查，直接传一个太小的 buffer 给它，会触发 CODES_WRONG_ARRAY_SIZE 错误，而不是静默截断。
常见错误现象：程序在某台机器上正常，在另一台 segfault——大概率是 buffer 大小没按实际数据点数量分配。
正确顺序：
- 先
codes_get_size(h, "values", &size)拿到元素个数size - malloc 或 vector
resize 到 size - 再
codes_get_double_array(h, "values", values, &size)—— 注意第三个参数是&size，不是size，函数会校验并可能改写该值 - 若返回
CODES_SUCCESS但size变小了，说明原 buffer 不够，需重试（不过通常 resize 后不会发生）
lat/lon 网格元数据不能只看 "latitudeOfFirstGridPoint" 这类 key
GRIB2 支持几十种网格定义（rotated lat/lon、lambert conformal、stereographic、reduced Gaussian…），仅靠 "latitudeOfFirstGridPoint"、"iDirectionIncrementInDegrees" 等通用 key 无法还原真实经纬度场。真正决定坐标的，是 "gridType" + 对应的 grid definition template（模板编号在 "gridDefinitionTemplateNumber" 里）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
使用场景举例：你拿到一份 ECMWF 的 rotated lat/lon 数据，发现算出来的 lon 全是负的、范围不对——问题就出在没识别 "gridType" == "rotated_ll"，也没读 "angleOfRotation" 和基准极点。
实操建议：
- 必查
codes_get_string(h, "gridType", grid_type, &len)，再分支处理 - 对
"rotated_ll"，还需读"latitudeOfSouthernPoleInDegrees"、"longitudeOfSouthernPoleInDegrees"、"angleOfRotation" - 对
"lambert"，要结合"Latin1InDegrees"、"Latin2InDegrees"、"DxInMetres"等计算投影坐标 - 别硬编码经纬度公式，优先用
eccodes自带的codes_grib_iterator_*接口遍历——它内部已适配全部模板
多线程读同一个 GRIB2 文件必须用 codes_open_file() + codes_file_close()
直接传 FILE* 给 codes_handle_new_from_file() 是线程不安全的——因为底层会做 fseek()、fread()，共享文件指针在多线程下互相覆盖位置，导致读出乱码或 CODES_CORRUPTED_DATA。
正确做法不是加锁，而是让每个线程独立打开文件：
- 用
codes_open_file(filename, "rb")获取codes_file*（它内部封装了线程安全的偏移管理） - 再用
codes_handle_new_from_file(0, codes_file*)创建 handle - 最后用
codes_file_close()关闭（不是 fclose） - 注意：不能混用
fopen()和codes_open_file()，前者返回的FILE*不可用于多线程 GRIB 解析
如果文件极大（>10GB），频繁 open/close 开销明显，可考虑预加载到内存后用 codes_handle_new_from_message()，但要注意 message buffer 必须完整包含一个 GRIB 消息（含 7777 结尾）。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
