SNAP-snappy批量处理Sentinel-1：正确设置NoDataValue的完整指南

SNAP 和 snappy 这套组合，做 Sentinel-1 批量处理是真的香，但如果你直接在 Python 脚本里跑完 GPF 然后导出 GeoTIFF，十有八九会撞到同一个问题：影像边缘那一圈无效值到底该怎么处理？我之前跑几百景 GRD 批量定标、地形校正，导出后放进 GIS 软件一看，黑边要么是 0，要么是 NaN，统计后向散射系数的时候，均值硬生生被这些无效值拉高，后来才搞明白罪魁祸首就是没有正确设置 nodata。其实核心操作很简单——在写出前给每个波段设置 NoDataValue，并打开对应的开关。但这件事往深了说，涉及 SNAP 的数据模型、写出格式的选择，以及和 GDAL 互操作时的各种细节，如果不搞清楚，调了半天问题依旧。

这篇就围绕“SNAP-snappy 二次开发里如何设置 Sentinel-1 数据的 nodata”这个点，把原理、代码、踩坑一次性讲透。适合用 snappy 写批处理脚本的人，尤其是不想每次都打开 SNAP GUI 点鼠标的开发者。无论你处理的是 GRD 强度数据、SLC 复数数据，还是做了干涉或极化处理，只要你最后要导出栅格给其他工具用，这篇都值得看完。

1. 为什么 Sentinel-1 的处理结果必须关心 nodata

1.1 Sentinel-1 数据里的无效值从哪来

很多人以为读进来的 Sentinel-1 产品是规规矩矩的矩形影像，每个像素都有真实的后向散射值，其实不是。Level-1 的 GRD 产品虽然已经做了多视和地距投影，但影像边缘尤其是近距和远距入射角较大的区域，仍然存在大量无效像素。这些像素在原始产品里可能对应着不完整的雷达回波，或者经过多视处理后没有足够的独立样本，SNAP 在内部会通过掩膜把这些区域标出来，但掩膜这个东西在导出格式里并不会自动变成标准 nodata 标记，非常容易丢。

更麻烦的是，处理链路里每一步都可能引入新的无效区。比如做地形校正（Range-Doppler Terrain Correction），输出网格会覆盖原始斜距数据映射不到的范围，这些地方通常是 0 或者 NaN；做镶嵌拼接时，相邻景重叠范围之外也会被填充默认值；滤波、重采样、转 dB 等操作也可能让某些边缘像素变成无效。所以你会发现，同样一份数据，处理到越后面，无效值的分布越复杂，表现形式也越乱——有的是 0，有的是 NaN，有的甚至是非常离谱的负值。

如果不统一管住这些无效值，它们就会混在真实数据里，跟你后面所有分析环节“捣乱”。我在实际项目中验证过：对一个研究区的 Gamma0 后向散射系数做平均值统计，无效值如果以 0 存在，均值会被明显拉高；如果以 NaN 存在，有的统计库会自动跳过，有的则会直接把整个结果变成 NaN，尤其是你用 numpy 直接操作像素数组时不加掩膜，几乎必炸。

1.2 不设置 nodata 会带来哪些实际麻烦

先列举几个常见场景，你就知道这个问题的覆盖面有多广了。

第一个场景是遥感指数或物理量反演。比如用 VV/VH 比值做土壤水分反演，如果某个像素边缘无效值恰好是 0，比值就会变成 0 或无穷大，反演结果直接报废。第二个场景是做长时间序列分析，你处理了同一区域 100 景影像，每景的无效值位置和值不统一，后面按像素时间序列提取时，无法用一个统一的条件把它剔除，只能每景单独处理，脚本复杂度立刻上涨。第三个场景是训练深度学习模型，很多语义分割模型读取 tif 后不做掩膜，无效区域一旦进入训练集，模型会学出“边缘区域是特定类别”这种错误特征。第四个场景是发布数据给同事或下游管线，GDAL 读取时如果识别不到 NoDataValue，默认会把那个数值当真实栅格值参与重采样，比如你导出到 WGS84 分辨率再重采样，黑边会像墨水一样扩散到有效区域。

这些问题的根源都在于：SNAP 内部的无效信息默认是没有映射到输出文件元数据里的。SNAP 的内存模型里，像素和掩膜是分开的，而常规栅格格式（尤其 GeoTIFF）只认一个统一的 NoDataValue 数字。如果不手动告诉 SNAP“哪些值是无效的、该写到文件头里去”，它就会把无效像素当成普通像素直接写盘。

2. SNAP 中 nodata 的底层表达方式

2.1 NoDataValue 是一个带“开关”的元数据

用 snappy 操作 SNAP 时，你面对的核心对象是 Product、Band 和 Mask。其中 Band 有一个看似不起眼但非常关键的属性对：NoDataValue 和 NoDataValueUsed。前者是一个浮点数，用来表示“这个波段里哪些像素值是无数据”；后者是一个布尔开关，用来表示“这个波段是否启用无数据值”。

这两个属性必须同时配合。只设置 NoDataValue 不把 NoDataValueUsed 设为 true，等于你告诉 SNAP“有这么一个值”，但没告诉它“请把它当作无数据来处理”，写出时大概率忽略；反过来，只把开关设为 true 却不设置具体数值，SNAP 内部会默认使用 NaN 作为 NoDataValue，这个值在 GeoTIFF 里虽然合法，但在很多统计工具和 WebGIS 服务里表现并不理想。

我自己在 snappy 里写代码时，习惯把它们当成一对来操作：

python复制band.setNoDataValue(-9999.0)
band.setNoDataValueUsed(True)

这两行代码就是整个 nodata 设置的核心。但要注意，setNoDataValue 的参数是浮点数，如果波段类型是整数（比如 UINT8），你设置的 -9999 会被截断或溢出，所以无效值的选择一定要在数据类型的合法范围内。比如常见的 Sigma0_VV 波段在 SNAP 里处理完后通常是 float32，用 -9999 没问题；如果是做分类结果输出，波段类型是 UInt8，那你就应该用 0 或者 255 作为无效值。

2.2 掩膜和 nodata 不是一回事

SNAP 中还有一个和 NoDataValue 长得像但完全不同的东西叫掩膜（Mask）。掩膜本质上是每个像素的 true/false 标记，比如 SNAP 默认会有一个名为 noData 的掩膜，用来标记哪些像素被判定为无数据。掩膜的优势是精确到像素级，可以表示任何不规则的无数据区域；而 NoDataValue 只是一个标量，只能表示“等于这个数值的像素是无数据”。

那这两者是什么关系？SNAP 在读写时会做一定的互相转换。例如当你设置某个波段的 NoDataValue 并打开开关后，SNAP 会在内部生成或更新对应的 noData 掩膜；同理，当你读入一个带有掩膜的产品时，SNAP 也可能用掩膜来推导 NoDataValue。但在二次开发中，你不能默认这个转换一定发生，尤其是用 GPF 算子生成的新产品，掩膜和 NoDataValue 经常是“各管各的”。

一个很典型的例子：你用 TerrainCorrection 算子处理完影像后，输出产品里边缘无效区域已经由内部掩膜标记，但你去 band.getNoDataValue()，返回的可能是 NaN，而 band.isNoDataValueUsed() 可能返回 false。所以面向输出的通用做法不是依赖掩膜，而是显式设置波段级的 NoDataValue。如果你希望同时保留更精细的无效区域，可以在设置 NoDataValue 之后再检查 product.getMaskGroup().get('noData') 是否存在，不存在就手动创建，或者用 Band.setNoDataValueUsed(True) 强制 SNAP 自动生成掩膜。

2.3 为什么不能简单用 0 或 NaN 来兜底

很多初学者会想：既然无效区域那么多，我干脆把所有无效值都改成 0 或者 NaN 不就行了？理论上可以，但实际执行有很多隐患。

先说 0。对后向散射系数来说，0 通常意味着“完全没有回波”，这在物理上不是绝对不可能的，尤其是平静水面在某些极化方式下，后向散射会非常低，接近 0。如果你把 0 直接标记为无效值，就等于把这些真实但极低的值全删了，会造成统计偏差。另外在很多雷达处理算子内部，0 还可能作为有效像素的初始值出现，比如做插值、滤波时，0 会导致计算不稳定。再说 NaN，GeoTIFF 格式对 NaN 的支持并不统一，有些写入器会把 NaN 存储为 IEEE 754 的特殊浮点数，但一些老旧 GIS 软件读到 NaN 后会直接崩溃；在做 Format 转换时，NaN 还经常被错误地当作极大或极小的数值参与运算。

所以行业惯例是选一个“偏离真实数据分布”的哨兵值，比如 -9999、-32768，或者 3.402823466e+38（float32 的 max）。这样既不会误伤真实低值，又能让下游软件一目了然地识别无效区域。要记住的是，NoDataValue 只是一个元数据标记，它并不会自动把像素里的值改成这个数值。如果你处理后的产品里像素值本身是随机产生的坏值（比如 NaN），你还需要额外做一步“像素替换”，把检测到的无效像素写成你设置的 NoDataValue，否则即便设置了元数据，文件里的 NaN 依然存在。

3. snappy 里设置 nodata 的几种典型路径

3.1 最直接的方式：遍历波段设置属性后写出

如果你已经有一个 Product 对象，最简单粗暴的方法就是对所有波段循环设置 NoDataValue 和开关，然后从 ProductIO.writeProduct 写盘。

python复制import snappy
from snappy import ProductIO

product = ProductIO.readProduct("S1A_IW_GRDH_1SDV_20230101T120000_20230101T120000_001_002_003.SAFE")

# 统一无效值
nodata = -9999.0

for band in product.getBands():
    band.setNoDataValue(nodata)
    band.setNoDataValueUsed(True)

# 写出为 GeoTIFF
ProductIO.writeProduct(product, "output_sigma0.tiff", "GeoTIFF")

这段代码看起来简单，但有几个细节必须强调。第一，product.getBands() 返回的是所有波段，包括一些派生的虚波段（如 Intensity、Phase 等），都给它们设置统一的 nodata 通常没问题。第二，如果产品是经过 GPF 算子生成的“虚拟产品”（virtual product），内存里只是一个算子链，并没有真正展开像素数据，直接 writeProduct 时 SNAP 会强制计算，这时候 NoDataValue 设置可能不生效，因为虚产品的波段属性是计算得到的，被算子链覆盖了。我遇到这种情况时，会先对产品执行一个“复制”操作，或者用下面的 Write-Graph 方式。

另外，写 GeoTIFF 时，SNAP 的 GeoTIFF writer 识别 NoDataValue 的行为在不同版本里有点差异。比较稳妥的做法是写完后用 GDAL 检查一下，确认文件头里确实写入了 NODATA_value。如果没生效，就换 3.2 里的方式。

3.2 通过 Write 节点和图形处理模板传参

SNAP 的图形处理工具（Graph Processing Tool，GPT）里，Write 节点通常有一个“写 no-data 值”的选项，在 Graph Builder 界面中可以在 Write 节点的属性面板里看到。你可以先在 Graph Builder 里拖一个 Read、一个 Write，配置好参数，保存成 XML 模板，然后用 snappy 加载这个模板，或者直接通过 GPF 的 HashMap 传参。

这里更推荐的做法是：用 Graph Builder 生成一个模板，看它生成的 XML 里 Write 节点的参数名是什么，然后在你的 snappy 脚本里复用这个模板。不同 SNAP 版本的参数名可能略有不同，最常见的写法类似：

xml复制<node id="Write">
    <operator>Write</operator>
    <parameters>
        <file>output.tiff</file>
        <formatName>GeoTIFF</formatName>
        <writeNoDataValue>true</writeNoDataValue>
    </parameters>
</node>

在这个 XML 里，writeNoDataValue 就是控制是否把波段 NoData 信息写入输出文件的开关。如果你在 snappy 里加载这个模板，它会在写出时自动把每个波段的 NoDataValue 写到文件头里。

用 snappy 执行这个图：

python复制from snappy import GPF

GPF.getDefaultInstance().getOperatorSpiRegistry().loadOperatorSpis()
params = snappy.HashMap()
params.put("file", "graph.xml")
graph = GPF.createProduct("Read", params)  # 通过 XML 加载图形, 实际上要用 GPF.loadGraph

其实更简洁的是直接通过 subprocess 调用 gpt 命令行，在命令行里设置 -PwriteNoDataValue=true，这样最不容易踩参数版本差异的坑：

bash复制gpt graph.xml -Ssource=/path/to/input -Poutput=/path/to/output.tiff -PwriteNoDataValue=true

如果你在 Ubuntu 上用 snap 安装过 SNAP，gpt 命令通常会在 /snap/snap/current/bin/gpt 路径下，通过 snap 安装的 SNAP 会有自己的环境变量，脚本里最好用绝对路径或者确保 PATH 里能找到。

3.3 最稳妥的方案：先写 BEAM-DIMAP 再转码

如果前面两种方式都不让你放心，或者你遇上了“设置了半天，GDAL 就是读不到 NoDataValue”的情况，还有一个百分百可控的兜底方案：先写出为 BEAM-DIMAP 格式（SNAP 的原生格式，后缀 .dim），再用 GDAL 或 SNAP 自己转成 GeoTIFF。

BEAM-DIMAP 的元数据是 XML，SNAP 会非常准确地把 noDataValue 属性记录在文件头里。当你把 .dim 文件用 GDAL 读出来并转成 GeoTIFF 时，GDAL 会自动告诉你这个波段有没有 NoDataValue，然后你再通过 gdal_translate 或 gdal_calc 输出，就能稳定写入 GeoTIFF 的 NODATA tag。

python复制# 第一步：用 snappy 写 BEAM-DIMAP
ProductIO.writeProduct(product, "output.dim", "BEAM-DIMAP")
# 第二步：用 GDAL 转 GeoTIFF
from osgeo import gdal
src = gdal.Open("output.dim")
dst = gdal.GetDriverByName("GTiff").CreateCopy("output_utm.tiff", src)
dst.GetRasterBand(1).SetNoDataValue(-9999.0)
dst.FlushCache()

这种方法的好处是你可以完全控制 NoDataValue 的数值和是否设置，缺点是中间多了一次磁盘写读，批量处理时会慢一些，而且 BEAM-DIMAP 会生成一堆附属文件，工作目录会显得比较乱。我一般用这种方法做“正式交付前的最后一次加工”，如果是在同一条流水线里反复迭代，还是优先用前两种。

4. 把 nodata 设置嵌入实际批量处理流程

4.1 一个完整的哨兵1批量处理脚本骨架

在实际的 snappy 二次开发里，你不会只处理一景影像，而是要对一整个目录、几十上百景做统一批处理。下面我提供一个自己常用的脚本骨架，你可以在它的基础上改。

python复制import os
import glob
import snappy
from snappy import ProductIO, GPF

# 初始化 GPF 算子
GPF.getDefaultInstance().getOperatorSpiRegistry().loadOperatorSpis()

NODATA = -9999.0

def apply_processing(input_path, output_path):
    # 1. 读取原始 GRD
    product = ProductIO.readProduct(input_path)

    # 2. 做辐射定标
    cal_params = snappy.HashMap()
    cal_params.put("outputSigmaBand", True)
    cal_params.put("sourceBands", "Sigma0_VV,Sigma0_VH")
    calibrated = GPF.createProduct("Calibrate", cal_params, product)

    # 3. 做地形校正
    tc_params = snappy.HashMap()
    tc_params.put("demName", "SRTM 1Sec HGT")
    tc_params.put("pixelSpacingInMeter", 10.0)
    tc_params.put("mapProjection", "WGS84(UTM 50N)")
    terrain = GPF.createProduct("Terrain-Correction", tc_params, calibrated)

    # 4. 统一设置 noData
    for band in terrain.getBands():
        band.setNoDataValue(NODATA)
        band.setNoDataValueUsed(True)

    # 5. 写出（优先用 GeoTIFF；如果出问题可切换 BEAM-DIMAP）
    ProductIO.writeProduct(terrain, output_path, "GeoTIFF")
    print("processed:", os.path.basename(input_path))

if __name__ == "__main__":
    input_dir = "/home/user/data/sentinel1"
    out_dir = "/home/user/data/out"
    for safe_path in glob.glob(os.path.join(input_dir, "S1*.SAFE")):
        out_path = os.path.join(out_dir, os.path.basename(safe_path).split(".SAFE")[0] + "_tc.tiff")
        apply_processing(safe_path, out_path)

这个流程把定标和地形校正串起来了，在所有处理结束、写出之前，统一设置了 NoDataValue。有一点要提醒：上面的 Calibrate 参数里 sourceBands 指定了 Sigma0_VV,Sigma0_VH，如果你的输入产品里没有这些波段，后面的地形校正会出错。写批处理脚本时一定要先打印一下输入产品的波段名，不要想当然。

4.2 防止漏掉任何一个波段

多波段产品最容易踩的坑是：你只给自己关注的波段设置了 NoDataValue，却忘了其它波段。比如 Terrain-Correction 输出产品里除了 Sigma0_VV、Sigma0_VH，还可能有 incidenceAngle 从散射计导出的波段，或者你后续自己添加了指数波段。如果这些波段没有设置 NoDataValue，在后面对每一波段做分析和发布时，仍然会有一堆 0 或 NaN 混进去。

我的建议是，不要用“我关心的波段名列表”去设置，而是直接遍历 product.getBands()，对每个波段都设置同样的 NoDataValue。同时，如果你的产品里有一些 Bands 的类型是虚波段，设置 NoDataValue 后，还要确保写入时它被“物化”了。所谓物化，就是让 SNAP 真的把数据算出来写到文件里，而不是只保留计算引用。如果你直接在虚产品上设置 NoDataValue 后调用 writeProduct，SNAP 在计算那个波段时，有可能会重新应用算子链里的默认 NoData 逻辑，把你设置的值覆盖掉。解决方式是先 product.copy() 一下（创建新的产品实例），或者通过 Write 节点的 writeNoDataValue 参数，明确保留属性。

另一个隐蔽问题是 tie-point 网格（比如纬度和经度网格）不是 Band，不需要设置 NoDataValue，但如果你用 GDAL 读取 DIM 文件时，这些网格会被当成普通波段读出来，它们同样可能有无效区。我在处理时一般会在写出前把不需要的 tie-point 网格从产品里移除，或者用 subSampling 参数控制输出波段。

4.3 写完后如何验证 NoDataValue 真的生效

设置完不能光靠感觉，必须验证。推荐两种方式。

第一种，在 snappy 里重新读回文件，检查波段属性：

python复制check = ProductIO.readProduct("output_sigma0.tiff")
band = check.getBand("Sigma0_VV")
print(band.getNoDataValue())
print(band.isNoDataValueUsed())

如果打印出来的 getNoDataValue() 是你设置的 -9999.0，且 isNoDataValueUsed() 为 True，说明 SNAP 内部认为写入成功。

第二种，用 GDAL 从文件层面确认：

bash复制gdalinfo output_sigma0.tiff

在输出信息里，你会看到类似：

code复制Band 1 Block=256x256 Type=Float32, ColorInterp=Gray
  NoDataValue=-9999

如果没有 NoDataValue 这一行，说明 GeoTIFF 文件头里没写进去，那就要用 3.2 或 3.3 的方案。

我实际经验是，ProductIO.writeProduct 写 GeoTIFF 时，SNAP 有时会“吞掉” NoDataValue，尤其是当产品经过了某些 GPF 算子链后。反而是通过 Write-Graph 或直接 gpt 命令行写出来的 GeoTIFF，能更稳定地保留 NoDataValue。如果你发现 SNAP 版本有这种问题，不要纠结，直接换一个路径。

5. 常见问题与排查实录

5.1 写了 NoDataValue，GDAL 读出来还是没有

这个是最常见的问题，几乎每个用 snappy 写 GeoTIFF 的人都会遇到。排查顺序如下：

1. 先确认是否调用了 setNoDataValueUsed(True)，只设置数值不打开开关，等于没设置。
2. 检查是否在写出前被某个算子覆盖了属性。可以在写出前打印一下 band.isNoDataValueUsed()，如果变成 False，说明中间有算子重置了属性。
3. 检查 SNAP 版本。老的 SNAP GeoTIFF writer 对 NoDataValue 的支持不稳定，升级到新版本后问题可能会消失。
4. 检查输出格式。如果你写的是 NetCDF，NoDataValue 会映射到 _FillValue 属性，GDAL 读取时可能显示为 _FillValue 而不是 NoDataValue，这不代表没写成功。
5. 最省事的方法是改用 BEAM-DIMAP 中转，或者直接用 gpt 命令行。

下面是一个快速排查用的 snappy 脚本片段：

python复制def check_band_nodata(path):
    product = ProductIO.readProduct(path)
    for band in product.getBands():
        print(band.getName(),
              "NoDataUsed:", band.isNoDataValueUsed(),
              "NoDataValue:", band.getNoDataValue())

5.2 处理过程中出现了大量 NaN

SNAP 内部很多算子在计算无效区域时会产生 NaN。比如地形校正中，没有 DEM 覆盖的区域、入射角过大区域，计算得到的后向散射系数可能就是 NaN。如果你把这样的产品直接写出来，即使设置了 NoDataValue，GeoTIFF 里仍然会保留 NaN 像素，因为 NoDataValue 只是“标记”，并不会自动替换像素值。

解决方案是显式做一次像素替换。你可以用 snappy 读取计算后的波段数组，把 NaN 替换成你设定的 NoDataValue，再写回产品，然后再写出。示例：

python复制import numpy as np
width = band.getRasterWidth()
height = band.getRasterHeight()
data = band.readPixels(0, 0, width, height, np.zeros((height, width), dtype=np.float32))
data[np.isnan(data)] = NODATA
band.writePixels(0, 0, width, height, data)

这里要注意 readPixels 返回的是一个 numpy 数组，但 SNAP 的 readPixels 接口类型需要你传入一个“可写数组”，所以上面的代码先创建了 np.zeros。如果你不替换 NaN，后面无论怎么设置 NoDataValue，GDAL 里都能看到 nan 值残留在栅格中。

5.3 多景数据拼接时边黑边不统一

批量处理多景 Sentinel-1 时，如果各景的无效值设置不统一（前一景用 0，后一景用 NaN，或者一个设置了 NoDataValue 一个没设置），在后续镶嵌时就会出现黑色接缝或者边缘异常。我的做法是在批处理入口就定义一个全局常量 NODATA，所有景、所有波段都用同一个值。这样到了镶嵌环节，只需忽略 NoDataValue 像素即可。

python复制NODATA = -9999.0

如果你做镶嵌用的是 SNAP 的 Mosaic 算子，记得在 Mosaic 参数里设置 invalidPixelValue 和 noDataValue，否则 Mosaic 默认可能把无效区域填成 0。我之前就是漏了这一步，镶嵌出来的 VV 图像边缘全是一条条 0 值黑线。

5.4 与 GDAL 互操作时 NoDataValue 仍被忽略

GDAL 读取 GeoTIFF 时，通常会识别 TIFFTAG_NODATA，但如果你的 GeoTIFF 里没有写入这个 tag，GDAL 会把 NoDataValue 视作 None。就算你在 SNAP 里设置了 NoDataValue，有些版本的 SNAP GeoTIFF 写入器不会把 NoDataValue 写出为标准的 TIFFTAG_NODATA。这是格式定义和实现的问题。

碰到这种问题，除了换 Write 方式外，还可以在 GDAL 读取后手动设置：

python复制from osgeo import gdal
ds = gdal.Open("output.tiff")
band = ds.GetRasterBand(1)
band.SetNoDataValue(-9999.0)
ds = None

但这属于事后补救，不是长久之计。最好的办法还是在生成阶段就用稳定路径。

下面整理一个速查表，方便你定位问题：

6. 实战中总结的几个小经验

这一节不聊理论，就说说我自己在项目里摸出来的几条土办法。

关于 NoDataValue 的取值，我最初统一用 -9999.0，但在一次处理 UINT16 波段时发现导出后值被截断成了 0，因为 -9999 根本不在 UINT16 的取值范围里。后来我就养成了习惯：先判断波段数据类型，再选 NoDataValue。float32 用 -9999.0，整数型用类型最小或最大值附近的数（比如 UINT8 用 255，UINT16 用 65535），这样既不会误伤真实数据，也能被 GDAL 正常识别。

还有一个细节是你设置 NoDataValue 之后，最好顺手检查一下 SNAP 自动生成的 noData 掩膜是否存在。如果你在 snappy 里用 product.getMaskGroup().get('noData') 拿到的是 null，说明该产品没有显式的 noData 掩膜，这会影响后续一些基于掩膜的算子。此时可以手动创建一个：

python复制from snappy import Mask
mask = Mask.BandMask("noData", band)
product.getMaskGroup().add(mask)

这个操作不是必须的，但如果你后面要做针对无效区的统计或可视化，有个显式掩膜会方便很多。

最后一个小技巧，也是很多人会忽略的：用 snappy 处理 Sentinel-1 时，如果你看到输出结果里边缘仍然有 0 值，先别急着改代码，去 SNAP GUI 里用同样的算子链跑一遍，查看“快视图”和波段属性，快速判断 NoDataValue 有没有被保留。GUI 能给你一个交互式检查的环境，比你在 Python 里反复 print 效率高得多。我多次遇到“代码写了、Gdal 没读到”的问题，最后都是用 GUI 对照检查才定位到是 SNAP 某个算子重置了 NoDataValue。

这套方法下来，基本能解决 Sentinel-1 处理中九成以上的无效值问题。以后你再拿 snappy 写批处理，应该不用再被边缘黑边和 NaN 折腾了。