xarray.to_netcdf使用scale_factor与add_offset导出int16数据出现异常负值

该问题不是xr.to_netcdf的bug，由两个核心原因导致：

1. int16量化的固有舍入误差
   你使用的打包逻辑是将[-9999, mapMax]范围的浮点值映射到int16的[-32768, 32767]整数区间，量化步长scale_factor = (mapMax + 9999)/65535。当mapMax=0时，步长约为0.1526，原始值0对应的打包整数值为(0 - add_offset)/scale，这个值几乎不可能刚好是整数，底层存储时会自动做四舍五入。解包时用packed_value * scale + add_offset计算原值，就会出现±半个步长以内的误差，也就是你看到的-0.0027这类微小负值，属于量化过程的正常误差。
2. _FillValue设置不合法
   你代码中计算的fvalue是浮点类型，而int16类型变量的填充值必须是整数。如果直接传入浮点值，底层HDF5库会自动做类型转换，可能导致你提前填充的-9999对应的打包值和_FillValue不匹配，本该识别为缺失值的单元格被当成正常数值解包，也会出现异常小值。

• 修正填充值计算逻辑，将fvalue显式转成int16整数：

fvalue = int(np.round((mv - offset)/scale))

• 如果你的业务场景允许微小误差，可以在读取数据后增加阈值截断逻辑，例如将绝对值小于1e-3的数值直接置为0。
• 若要完全避免0值的误差，可以调整compute_scale_and_offset的逻辑，强制0值对应整数的打包位置，或者在mapMax=0时单独设置scale和offset，避免量化误差落在0值附近。
• 将NaN替换逻辑移出变量遍历循环，避免重复全局修改数据集：

# 循环外统一处理缺失值
mv = -9999
ds = ds.fillna(mv)
encoding = {}
for data_var in ds.data_vars:
    # 原有的scale和offset计算逻辑
    ...

你可以用xarray读取生成的netCDF文件，和原始数据集做差值统计，所有误差都不会超过scale_factor/2，符合int16量化的误差范围，可以排除xr.to_netcdf的功能bug。

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