nc_open后需遍历所有组（nc_inq_grps）并分别调用nc_inq_ndims/nc_inq_dimid/nc_inq_dim获取维度，注意跨组dimid无效、UNLIMITED判据为NC_UNLIMITED宏值、坐标变量须满足存在且唯一维度匹配，推荐C++ RAII封装防泄漏。
nc_open后怎么安全读取Dimensions列表
直接调用 nc_inq_ndims 和 nc_inq_dimname 是基础，但容易忽略 NetCDF4 的分组（group）结构——根组之外的维度可能藏在子组里。如果只对根组调用 nc_inq_ndims，会漏掉嵌套维度。
正确做法是：先用 nc_inq_grps 获取所有组 ID，再对每个组分别调用 nc_inq_ndims + 循环 nc_inq_dimid + nc_inq_dim。注意 nc_inq_dim 返回的 len 是尺寸值，is_unlimited 字段需用 NC_UNLIMITED 比较，不是布尔值。
- NetCDF4 中维度可被多个组“共享”，但
nc_inq_dimid在非定义组中返回NC_EBADDIM，需捕获错误而非跳过 - 维度名可能含斜杠（如
"/g1/time"），但nc_inq_dimname返回的是纯名称，路径信息需靠当前组上下文推断 - 用
nc_inq_dim时传入的dimid必须来自该组，跨组复用dimid会导致未定义行为
如何区分常规维度和坐标变量（Coordinate Variables）
NetCDF4 规范里，“维度存在”不等于“有对应坐标变量”。比如定义了维度 "lat"，但没创建同名变量，那它只是个长度占位符；反之，若存在变量 "lat" 且其唯一维度就是 "lat"，才是坐标变量。
判断逻辑必须两步走：先查变量是否存在（nc_inq_varid），再查该变量的维度数（nc_inq_varndims）和维度 ID 列表（nc_inq_vardimid），确认是否为 1 维且维度 ID 对应目标维度。
立即学习“C++免费学习笔记（深入）”；
-
nc_inq_varndims返回 0 表示标量变量，不能算坐标变量 - 同一维度名可能对应多个变量（如
"time"和"time_bnds"），仅靠名字匹配不严谨，必须核对dimid - 某些文件用
coordinates属性显式关联坐标（如"lon lat"），这时即使变量不是一维，也要按属性解析
处理无限维度（UNLIMITED DIMENSION）的边界陷阱
NetCDF4 允许一个组最多有一个无限维度，但 nc_inq_dim 返回的 len 值在文件刚创建时尚未写入数据时为 0，不代表维度为空——它只是尚未追加记录。误判为“空维度”会导致后续 nc_get_vara 出错。
可靠判断方式：检查 nc_inq_dim 的 len 是否等于 NC_UNLIMITED 宏值（通常为 0x7FFFFFFF），而不是看数值大小；同时用 nc_inq_dimlen 获取当前实际长度（该函数在无限维度上返回真实已写入的记录数）。
-
nc_inq_dimlen在非无限维度上等价于nc_inq_dim的len，但在无限维度上更准 - 调用
nc_inq_dimlen前必须确保文件以读写模式（NC_WRITE）打开，只读模式下可能返回NC_EACCESS - 多线程读取时，无限维度长度可能在两次调用间变化，需加锁或接受最终一致性
用 C++ RAII 封装维度查询避免资源泄漏
原生 NetCDF-C API 要求手动配对 nc_open/nc_close、nc_inq_grps 分配的内存需 free，C++ 项目里裸用极易出错。建议用轻量 RAII 类管理组 ID 列表和维度元数据。
例如封装一个 NcGroup 类，在构造时调用 nc_inq_ndims 并预分配 vector 存储 dimid，析构时自动释放；维度信息（名、长、是否无限）用 struct 值语义存储，避免生命周期依赖 NetCDF 文件句柄。
- 不要在 RAII 对象里缓存
char*指向nc_inq_dimname的内部缓冲区——那是临时栈内存，立刻失效 - NetCDF4 的 HDF5 后端可能让
nc_close变慢（尤其大文件），RAII 析构时机要可控，别在 hot path 上频繁开闭 - 若需跨线程共享维度信息，struct 内容必须是 POD 类型，避免隐式调用
std::string构造函数引发异常
