未指定encoding时to_netcdf保存netCDF后部分值变nan的问题

问题现象 #

1. 保存前验证数据无NaN：

ds.where(lambda x: x.isnull(), drop=True).coords

# 输出结果：
# Coordinates:
#   * x        (x) float64 
#   * y        (y) float64 
#   * time     (time) datetime64[ns] 
#     lon      (x) float64 
#     lat      (y) float64 

2. 执行保存操作：

ds.to_netcdf("manual_save.nc")

3. 重新加载后出现单个NaN：

xr.open_dataset("manual_save.nc").where(lambda x: x.isnull(), drop=True).coords

# 输出结果：
# Coordinates:
#   * x        (x) float64 -3.5
#   * y        (y) float64 57.0
#   * time     (time) datetime64[ns] 2023-02-01
#     lon      (x) float64 -3.5
#     lat      (y) float64 57.0

排查细节 #

• 受影响数据项原数值为275.88766，加载后变为NaN；
• 原数据为dask.array，提前compute或保存时指定compute=True均无法解决；
• 保存为zarr格式仍出现相同问题；
• 仅通过encoding指定zlib压缩（complevel=1）可解决该问题；
• 问题源于不稳定的NetCDF文件，重复保存会触发数值变为NaN。

原因分析 #

这种情况通常和浮点数精度的二进制存储/读取偏差或NetCDF默认无压缩时的磁盘写入异常有关：

1. 未指定压缩时，NetCDF默认以原始二进制格式写入浮点数，部分无法被二进制精确表示的特定数值（如275.88766）可能在写入/读取过程中出现位翻转，被解析为NaN；
2. Dask延迟计算的特性并非问题核心，提前compute后问题仍存在，说明根源在底层存储机制；
3. 启用zlib压缩时，数据会经过压缩编码/解码的校验流程，相当于给数据增加了一层校验，避免了原始写入时的位错误。

解决方案 #

1. 强制指定压缩编码：保存时通过encoding参数为变量添加zlib压缩，这是最直接有效的方法：

# 为所有数据变量设置zlib压缩
encoding = {var: {"zlib": True, "complevel": 1} for var in ds.data_vars}
ds.to_netcdf("stable_save.nc", encoding=encoding)

2. 更新依赖库版本：升级netCDF4和xarray到最新稳定版，旧版本可能存在已知的写入/读取bug：

pip install --upgrade xarray netCDF4

3. 显式指定数据类型：保存时为变量明确指定dtype，避免自动类型转换带来的精度问题：

encoding = {var: {"dtype": "float64"} for var in ds.data_vars}
ds.to_netcdf("typed_save.nc", encoding=encoding)

内容的提问来源于stack exchange，提问作者euronion