一个做遥感数据处理的朋友十有八九都遇过这种场景从某个数据平台下载了一批气象或者环境变量数据打开一看全是.nc后缀的 NetCDF 文件而下一环节不管是进 GIS 软件做分析还是丢给深度学习模型当训练样本人家只认带坐标信息的 GeoTIFF。我最早接触这批格式转换时也踩过不少坑尤其是“转出来的 tif 为什么是黑的”“为什么位置对不上”这类问题前前后后折腾了不少时间。这篇内容就是把我在实际项目里把 NetCDF 转成单个 GeoTIFF 的整套思路、命令和踩坑过程完整梳理一遍适合刚接触气象/海洋遥感数据、或者被 GDAL 命令行和 Python 库绕晕的读者直接拿来参考。很多人以为 NetCDF 转 GeoTIFF 就是把后缀名改一下或者用 GIS 软件“导出”一下就行实际上这里面的关键不在格式外壳而在空间参考、变量提取、缩放因子、无效值处理这些细节上。转不好数据即使打开了也是错的。这篇文章涉及的完整链路包括数据预检、子数据集定位、gdal_translate 核心转换、CRS 定义与裁剪、Python 批处理方案以及我在实操中遇到的典型问题和排查思路基本覆盖从入门到能自己动手解决问题的各个阶段。1. 项目背景与核心需求拆解1.1 NetCDF 与 GeoTIFF 的本质差异NetCDFNetwork Common Data Form最早是气象和海洋学界为了存科学数据设计的自描述格式它跟普通图像格式最大的不同是数据本身可以包含多维变量、全局属性、坐标体系说明。比如一个海表温度文件里面除了温度数值矩阵还带着经纬度坐标、时间维度、数据单位、有效值范围等元数据。这种结构非常适合科学计算但对普通 GIS 工具并不友好——很多软件打开 nc 文件之后只能看到一团黑或者一堆不知道什么意思的波段。GeoTIFF 则是地理空间影像的通用交换格式它把像素矩阵和地理配准信息像元大小、原点坐标、投影坐标系打包在一起任何 GIS 软件都能直接识别、叠加、渲染。正因为两者设计目标不同转换时最大的任务其实是“把 NetCDF 里面我们关心的那个变量提取出来然后补上 GeoTIFF 需要的地理坐标信息”。如果源文件里本身带经纬度变量这一步还算顺利最怕的就是坐标系描述不规范或地球投影使用非标准网格转换过程中还要额外处理重投影。另外要留意NetCDF 通常一个文件里可以塞很多变量而 GeoTIFF 一个文件对应一个栅格波段或一组波段。所以“将 NC 转成单个 GeoTIFF”这个需求翻译成技术语言就是选定目标变量按经纬度或投影坐标把数据组织好写出一个带空间参考的 geotiff 文件。理解了这个本质之后后续所有操作思路都会清晰很多。1.2 为什么一定要转成单个 GeoTIFF可能有人会问直接让下游工具去支持 NetCDF 不就行了吗理论上可以但现实中不现实。第一很多成熟 GIS 桌面端虽然能读 NC但在做镶嵌、切片、矢量化、模型训练数据准备时处理效率远不如 GeoTIFF第二NetCDF 多维结构容易引发“维度顺序不同导致读取结果转置”这类隐性 bug而 GeoTIFF 的二维栅格结构天然规避了这种问题第三基于文件路径就能精确定位数据区域、无需额外安装科学数据库依赖这对业务系统集成非常重要。就我个人的项目经验来说用单波段或者多波段 GeoTIFF 作为中间存储格式还有一个额外好处能让不同来源的栅格数据有统一的数据口径。比如同时处理气温、降水、风速多个变量时把每个变量转成独立 GeoTIFF 后就可以统一用 GDAL 的 intersection 逻辑对齐网格、统一裁剪处理流程简单且不容易出错。特别是当你后面还要做时间序列分析时每个时间切片转成一个 tif比维护一个巨大的 nc 文件并反复切片要轻量得多。1.3 转换方案的整体选型我自己试过三套方案一是直接用 QGIS 打开 NC 文件后右键导出二是用 GDAL 自带的 gdal_translate 命令行工具三是用 Python 的 xarray rioxarray 做灵活批处理。三套方案各有适用场景。QGIS 方案最直观适合偶尔转一次文件、且对坐标参数不太熟悉的人缺点是手动操作多、批量处理麻烦而且部分复杂 NC多个子数据集、带旋转网格处理起来不够透明。gdal_translate 方案是所有方案里最稳的性能好、命令简洁、容易写进批处理脚本前提是你得懂一点命令行基础。Python 方案最灵活适合当数据需要筛选、重采样、合并等预处理时用它一把梭代码可以复用也方便集成进更大的数据处理流程。我的建议是核心原则是“能命令行就命令行该编程就编程”。当你只需要转换 10 个文件gdal_translate 一条命令跑完当你有 1000 个文件、且需要处理不同成员变量时优先封装 Python 脚本。下面第 3、4 节我会分别把两种主流方式拆开讲并给出可直接套用的配置和脚本。2. 转换前的数据勘察先搞清楚你的 NC 文件里有什么2.1 用 ncdump 快速读取文件结构拿到 NC 文件先别急着转先把文件内部结构摸清楚。我最常用的工具是 ncdump这是 NetCDF 官方发布自带的一个命令能直接打印文件头信息。执行下面这行命令ncdump -h example.nc这会输出文件的所有维度、变量定义和全局属性。比如你会看到类似这样的信息netcdf example { dimensions: lon 1440 ; lat 720 ; time 365 ; variables: float lon(lon) ; lon:long_name longitude ; lon:units degrees_east ; float lat(lat) ; lat:long_name latitude ; lat:units degrees_north ; double time(time) ; time:long_name time ; time:units days since 1900-01-01 ; float tas(time, lat, lon) ; tas:long_name Near-Surface Air Temperature ; tas:units K ; tas:_FillValue 1.0000000409184788e20f ; tas:scale_factor 0.00249096296895251 ; tas:add_offset 220.766655626837 ; ... }从这段头文件里我们能获取几个关键信息维度顺序是 time→lat→lon变量名是 tas单位是开尔文还有 _FillValue、scale_factor、add_offset 等属性。“数据能不能转对”一半答案都藏在这几行里。如果你没装 ncdump用 Python 的 netCDF4 库也能实现同样效果但对快速查看来说命令行是最快的。2.2 用 GDAL 查看 NC 的子数据集结构GDAL 把 NetCDF 文件封装成多子数据集结构所以直接用 gdalinfo 也能看。命令gdalinfo example.nc输出里你会看到形如下面的内容Subdatasets: SUBDATASET_1_NAMENETCDF:example.nc:tas SUBDATASET_1_DESC[365x720x1440] Near-Surface Air Temperature (K)如果你只需要处理某个变量记下SUBDATASET_1_NAME的值后面 gdal_translate 都要用这个完整标识。需要提醒的是gdalinfo 对 nc 的解析基于 GDAL 内部的 NetCDF driver它只能“看到”它认得的变量遇到非常规结构比如投影网格、非规则网格时GDAL 能识别的子数据集可能比你预期的要少或者只把经纬度数组当成辅助信息。所以我的习惯是先用 ncdump 看物理结构再用 gdalinfo 看 GDAL 视角下的组织结构两者互为补充。只有物理结构里确实存在规则的二维经度/纬度变量或者是一维 lon/lat 组合成的笛卡尔网格GDAL 才能自动完成地理定位。否则后面还需要加-a_srs甚至重新投影处理复杂度就上去了。2.3 搞清坐标变量与空间参考转换过程中最容易翻车的就是坐标参考系。有两种常见情况。第一种是规则经纬度网格NC 文件里带一维 lon 和 lat 变量。这种情况下 GDAL 可以利用坐标变量自动生成地理配准信息目标输出的空间参考通常是 EPSG:4326WGS84 经纬度。大部分气象海洋再分析数据都是这种结构也是最简单的一种。第二种是非规则网格或投影网格比如区域气候模式输出经纬度变量是二维数组形状和变量一致或者数据本身在 Lambert 投影、极地立体投影等坐标系下。这种数据直接用 gdal_translate 会丢失空间位置信息需要先用文件属性里的投影定义构造参数或者用 xarray 重采样到规则网格后再转 GeoTIFF。对新手来说遇到第二种情况时我最推荐的策略是先在 GIS 软件里可视化验证一遍确认坐标系统能被正确读取再决定要不要做重投影或插值。在转之前还要特别注意变量属性的单位。比如 NC 里的温度变量单位是 K但业务系统往往要摄氏温度这时可以在转换阶段直接用-scale参数结合加减偏移换算或在 Python 里做换算后重新写文件。单位不一致是下游分析中常见的“神秘偏差”来源之一必须提前处理掉。3. 核心实操gdal_translate 转换单个 GeoTIFF3.1 基础转换命令与参数解析当你确认了要转换的变量和 NC 文件本身是规则网格后最核心的命令就一行gdal_translate -of GTiff NETCDF:input.nc:tas output.tif这个命令的意思是把输入文件input.nc中的tas变量以 GeoTIFF 格式输出为output.tif。默认情况下GDAL 会保留变量的原始数值和填充值不进行任何缩放。如果 NC 文件只有一个变量也可以省去NETCDF:input.nc:变量名这层写法直接写gdal_translate -of GTiff input.nc output.tif但我建议永远保持显式声明因为大多数 nc 文件并不只有一个变量。如果你希望在转换过程中顺手进行缩放和偏移计算比如把温度从开尔文转成摄氏度可以这样写gdal_translate -of GTiff -ot Float32 -scale -272.15 0 0 0 NETCDF:input.nc:tas output_celsius.tif这里-scale的语法是“输入最小值 输入最大值 输出最小值 输出最大值”也就是把原始值的某个区间线性映射到目标区间。但它不会自动应用 NC 文件里的 add_offset 和 scale_factor 属性。GDAL 在读取变量时其实会默认自动应用scale_factor和add_offset这个在很多文档里不太显眼但确实如此。真正需要你自己做单位换算的是把 K 变成 ℃ 这种“数据本身含义”的转换而不是原始存储值的缩放。3.2 处理 scale_factor、add_offset 与无效值我在实际工作中遇到最多的问题就是“转换后的数值跟原始文件对不上”。这里最常见的原因有三个一是没有意识到 GDAL 已经自动应用了 NC 变量里的 scale_factor/add_offset导致你在此基础上又额外缩放了两次二是没有处理好无效值和有效值范围三是选错了变量。举个例子某个 NC 变量存的原始整型值是比如 2200它的属性写着scale_factor0.01、add_offset200那么真实物理值就是2200*0.01 200 222。GDAL 读取时默认会自动还原这个真实物理值所以你在输出 GeoTIFF 里看到的就是 222 而不是 2200。如果你手动再加-scale 0 5000 0 50实际上是对已经还原的浮点值又做了一次强行映射这往往不是你想要的效果。对于无效值GDAL 的 NetCDF driver 会把_FillValue或missing_value自动映射为 GeoTIFF 的 None 像素但有时这两个属性同时存在且值不一致就可能导致某些像素没被正确识别为无效。因此我会建议在转换前用 ncdump 确认两个属性是否存在如果存在且不一致最好在转换后单独用代码把异常值重新置为 NoData。简单操作可以在gdal_translate里加上-a_nodata参数gdal_translate -of GTiff -a_nodata -9999 NETCDF:input.nc:tas output.tif这样能强制输出文件的无效值标记为 -9999避免下游分析时把你不要的观测空隙当成真实数据。3.3 定义或修正输出投影规则经纬度网格通常不需要额外定义投影GDAL 自动就能把 GeoTransform 写进去。但有些文件缺少明确的坐标系信息或者只有一个笨拙的grid_mapping属性。遇到这种情况输出 tif 即使能打开也会因为没有投影而无法和别的数据叠加。补救办法是显式定义投影比如强制设为 WGS84gdal_translate -of GTiff -a_srs EPSG:4326 NETCDF:input.nc:tas output_wgs84.tif-a_srs是“assign SRS”的意思它只修改输出文件的坐标参考属性不会重投影像素值。只有当源数据本身就是经纬度网格但投影信息缺失时才适合用-a_srs。如果源数据本身在别的投影里比如 Lambert 或 UTM而你想输出 WGS84/Web Mercator那就必须用真正的重投影工具比如gdalwarp -t_srs EPSG:3857 -r bilinear output_wgs84.tif output_mercator.tif这里我没有直接省掉中间文件原因是先转成 GeoTIFF 再做重投影便于排查每一步的问题。想一条命令完成也可直接把 gdalwarp 的输入设为NETCDF:input.nc:tas就行但为了后续排查方便还是建议分步写清模块尤其是处理不常见投影时。3.4 裁剪研究区域转换的同时完成空间子集很多业务场景只需要某个区域的数据比如某个流域、某个省份。我经常在转换命令里直接加-projwin一步到位省得后面再开 GIS 裁剪。语法是gdal_translate -of GTiff -projwin umin umax lmax lmin NETCDF:input.nc:tas output_subset.tif注意这四个值的顺序是“上左X、上左Y、下右X、下右Y”对应的是输出范围的外包矩形。如果是经纬度坐标就是西经、北纬、东经、南纬。比如想提取东经 100 到 120、北纬 20 到 40 的范围gdal_translate -of GTiff -projwin 100 40 120 20 NETCDF:input.nc:tas subset.tif这一步本质是先让 GDAL 根据窗口范围计算像素偏移再做大范围裁剪所以目标文件的行列数会比原文件小很多速度快、占空间少。需要提醒的是-projwin要求输入的坐标和源文件投影一致如果源文件是经纬度这四个数就是经纬度如果源文件是 UTM那你得先写成 UTM 坐标否则裁剪结果会偏到天边去。这个坑我一度每次都会踩后来干脆做一个“转换裁剪”的脚本模板彻底解决了。4. 进阶方案用 Python 批量处理与复杂场景4.1 为什么还需要 Pythongdal_translate 虽然高效但在两种场景下并不够用一是你需要先对 NC 数据做重采样、降维、平均、异常值过滤等操作这时候用命令行硬凑会很痛苦二是当你有几百上千个 NC 文件需要一键处理时Python 脚本比 shell 循环更好维护也更方便记录处理日志和校验结果。所以我通常建议项目里既有 gdal_translate 兜底又有 Python 脚本做复杂批处理两者分工明确。这里我主要用xarray和rioxarray两件套。xarray 是科学计算界处理多维数组的标准库它的数据结构跟 NetCDF 的思维一致处理维度、坐标、属性非常顺手rioxarray 则是 xarray 和 rasterio 之间的桥梁让 xarray 的 DataArray 可以直接写出带地理坐标的 GeoTIFF。如果你之前没用过pip install xarray rioxarray netCDF4一条命令装完就能用。4.2 读取 NC 并按要求筛选变量先从读取和筛选讲起。拿典型的气温数据举例import xarray as xr ds xr.open_dataset(input.nc) # 查看结构 print(ds) # 选择变量并保留必要坐标 tas ds[tas] # 如果有多时间层只取第一天 tas_day1 tas.isel(time0) # 或者对整段时间求平均 tas_mean tas.mean(dimtime)读取后你可以先用tas.attrs检查单位、填充值等信息。xarray 会把_FillValue自动转换成 NaN这部分相对省心。不过遇到scale_factor和add_offset时xarray 默认也会在读取时自动应用所以拿到的数组就是物理值。如果某些文件的缩放属性没被自动应用你可以手动还原tas_raw ds[tas] tas_physical tas_raw * tas_raw.attrs.get(scale_factor, 1) tas_raw.attrs.get(add_offset, 0)这里小心一点属性可能是字符串要做类型转换否则会报错或得到奇怪结果。更稳妥的方式是写一个小函数专门解析scale_factor和add_offset。4.3 用 rioxarray 写出单个 GeoTIFF当数据整理好了写 GeoTIFF 的代码非常简洁import rioxarray # 确保坐标变量被识别为空间坐标 tas_mean tas_mean.rio.set_spatial_dims(x_dimlon, y_dimlat, inplaceFalse) # 设置坐标系规则经纬度网格一般就是 WGS84 tas_mean tas_mean.rio.write_crs(EPSG:4326, inplaceTrue) # 写出 GeoTIFF tas_mean.rio.to_raster(output_mean.tif, driverGTiff, dtypefloat32)这就是“将 NC 文件转换成单个 GeoTIFF”的 Python 版最小实现。要注意set_spatial_dims在源数据里没有显式指定 x/y 维度时尤其重要。有些 NC 文件的纬度变量方向是反的从北到南rasterio 或 rioxarray 不会自动调整写出的 GeoTIFF 垂直方向会颠倒。解决办法是手动按纬度重排tas tas.sortby(lat)这个逻辑要养成习惯因为经过纬度排序之后后续任何重投影和裁剪都不容易出现错位。如果想在写出前顺手完成重采样可以用rio.reprojecttas_reproj tas_mean.rio.reproject( EPSG:4326, resolution0.25, resamplingrasterio.enums.Resampling.bilinear, )这样能统一不同数据源的分辨率方便后续做多变量融合分析。当然如果只是简单转换不涉及重投影rio.to_raster一步到位就行。4.4 批量处理脚本实战批量处理是 Python 方案最大的优势。我写过一个简洁的批处理骨架逻辑分三步遍历文件、读取目标变量、写出 GeoTIFF。核心代码大致如下from pathlib import Path import xarray as xr import rioxarray input_dir Path(./nc_data) output_dir Path(./tif_output) output_dir.mkdir(exist_okTrue) for nc_path in input_dir.glob(*.nc): print(fProcessing: {nc_path.name}) ds xr.open_dataset(nc_path) if tas not in ds.variables: print(f Skip, no tas variable.) continue data ds[tas].mean(dimtime, keep_attrsTrue) data data.sortby(lat) data data.rio.set_spatial_dims(x_dimlon, y_dimlat) data data.rio.write_crs(EPSG:4326) out_path output_dir / f{nc_path.stem}_tas.tif data.rio.to_raster(out_path, dtypefloat32) ds.close() print(All done.)这个脚本虽然只有 20 行左右但已经覆盖了批量、检查和写出几个核心环节。在实际项目里我会在循环里再加上日志记录、异常捕获和结果校验确保某个文件处理失败时不会中断整个任务。比如加一个 try/except记录失败的路径到 error.log 中方便后续排查。5. 常见问题、排查思路与避坑经验5.1 常见的 CRS 与坐标颠倒问题转换后 GeoTIFF 在 GIS 里位置偏移、颠倒或是压根没有坐标信息这是反馈最多的问题。位置偏移多半是-a_srs参数缺失或源文件的坐标变量有误上下颠倒则是因为纬度是从北到南排列GDAL 默认从下到上导致显示翻转。排查思路可以总结为一个三步法先gdalinfo output.tif查看Pixel Size、Origin和Coordinate System确认输出文件的 GeoTransform 是否符合预期。再看源文件变量维度顺序。如果维度是(time, lat, lon)GDAL 通常能正确读出如果顺序是(time, lon, lat)就需要在 Python 里转置或先ncdump -h确认。最后用 QGIS 快速叠加一个已知坐标的底图看数据是否落在正确位置。如果偏了就用gdalinfo对比输入和输出的坐标范围判断是投影问题还是坐标方向问题。坐标颠倒的显著特征是数据上下镜像。如果lat数组是递减的而你没排序就直接写 GeoTIFF那么输出的图像在纬度方向上就是反的。这个问题在气象数据里格外常见尤其是在从某些再分析数据源下载时。解决办法就是在 Python 里sortby(lat)或者在 gdal_translate 里加-ot Float32后使用gdalwarp会自动重排但后者效率相对较低不如直接源码排好。5.2 多维时间变量如何选择输出很多 NC 文件包含time维度一次转成单波段 GeoTIFF 时需要明确是取某个时间切片、还是对整个时间维度做平均/求和。如果你是取单时间点gdal_translate默认支持用子数据集格式里的索引吗实际上GDAL 的 NetCDF driver 默认不支持直接按时间索引选取只能读取变量的全部数据你需要先裁剪或聚合。因此更灵活的方式是走 Python 路线用isel(time0)或sel(timeslice(2020-01-01, 2020-12-31))处理好再写出。如果你特别依赖命令行也可以考虑先把 NC 用ncks或cdo之类的工具把时间维度截取成一个时间层然后gdal_translate再转换。我个人更建议在批量处理流程里直接对时间维度做“先聚合再转换”。比如要生成日均温数据就把一天 8 次观测先mean(dimtime)这样最终 tif 就是一个图层文件大小和后续处理负担都小很多。反之如果你想要时间序列的每个切片那就在循环里按time分组分别写出 tif并注意文件命名最好带上时间标识比如tas_20200101.tif否则后续时间匹配会让人抓狂。5.3 大文件转换的内存占用与执行效率如果要转换的文件非常大比如全球 0.1 度分辨率的逐日数据单个时间层就有几千万像素这时候转换过程可能出现内存占用过高或磁盘写满的问题。命令行里gdal_translate默认不将全部数据加载到内存它内部有分块读取机制所以一般还能撑住。真正吃内存的是 Python 方案——xarray 默认会把数据全部读进内存如果文件过大建议用chunks参数配合dask做分块处理。具体可以这样做ds xr.open_dataset(large.nc, chunks{time: 1})然后再写eto_raster时rioxarray会调用rasterio的分块写盘逻辑避免一次性占用过大内存。如果数据分辨率极高也可以在写出前降采样比如先coarsen或resample到更粗的网格再写 GeoTIFF。这在做全国乃至全球尺度可视化时非常有效比硬扛全分辨率数据再压缩要快得多。另一个效率技巧是使用 COGCloud Optimized GeoTIFF格式输出让生成的 tif 自带金字塔和分块结构后续访问速度更快。gdal_translate 命令可以这样写gdal_translate -of COG NETCDF:input.nc:tas output_cog.tif如果用的是 rioxarray可以这样tas_mean.rio.to_raster(output_cog.tif, driverCOG, dtypefloat32)COG 本质上也是 GeoTIFF但它的内部组织方式更适合网络访问和快速预览适合发布到地图服务或共享给其他团队。5.4 常见问题与排查技巧速查表为了让你在实际操作中能快速索引我把转换过程中最常见的现象、原因和解决办法整理成一个速查表方便贴在手边对照。现象可能原因排查与解决输出 tif 全黑或全白像素类型不对或数据值域集中用gdalinfo -stats查看像素统计用-scale或 Python 做值域拉伸确认是否选了错误的波段输出 tif 没有坐标信息NC 缺少空间参考或 GDAL 未识别用gdalinfo查看Coordinate System is:行如果是空用-a_srs EPSG:4326强制指定影像上下翻转lat 维度递减但未排序Python 里sortby(lat)或在转换后用gdalwarp -t_srs EPSG:4326重新对齐数值比预期大/小很多未处理 scale_factor/add_offset或重复缩放ncdump -h查看属性确认 GDAL 已自动应用后不要在命令里重复-scale无效区域显示为极小/极大值_FillValue未正确映射使用-a_nodata设置 NoData或用 Python 过滤后用 NaN/指定值写出目标范围不对-projwin坐标使用了与源文件不一致的投影确认阅读源文件投影先转成目标 tif 再gdalwarp裁剪多个变量只转出部分子数据集选择错误用gdalinfo查看所有SUBDATASET_*_NAME确保引用正确变量名内存不足大文件一次性读取用chunks分块或先降采样再写或改用 gdal_translate5.5 几条独家避坑经验最后分享几条我踩过很深、非常规文档里不会特意提醒的经验。第一永远保留源文件的备份和元数据信息。有些 NC 文件在转换后原始属性比如单位、时间覆盖范围、版本说明并不会完整保留到 GeoTIFF 里如果后续分析需要溯源你会很被动。我在实际项目里会把关键属性单独保存成一个 JSON 或 txt 文件放在转换目录下也算是给自己留一条后路。第二验证不能省。转换后至少做一次数值验证最简单的办法是随机抽几个像素坐标对比源 NC 中对应位置的值和输出 tif 中的值。可以直接在 Python 里读回 tif 再和 xarray 的结果比对。别小看这一步能帮你发现坐标翻转、变量错位、缩放错误等隐形问题。第三如果你的数源数据用到了非标准网格比如旋转极地网格或者三角形网格那么 GDAL 不能直接转换常规方法是先把数据插值到规则经纬度网格再走上述流程。插值时最好使用xesmf或scipy.interpolate具体选择取决于数据规模和精度要求。这一块内容比较多这里不展开但想提醒的是遇到“转出来是斜的或乱的”时别急着怀疑工具先想想是不是网格本身就不规则。第四能用 COG 出的尽量出 COG。不只是给下游“看数据”更快很多云平台也直接认 COG 格式后续和对象存储对接时能省不少事。这个经验在很多项目里真的值回票价。我在实际项目里的工作流基本固定下来了先ncdump -h快速定位变量接着用 gdal_translate 做一次单文件试点确认像素值和坐标都对再上 Python 批处理跑全量。整个过程没有太多花活但非常稳。