企业官网建设流程全解析

上周我为了补齐某试验区的时间序列影像，在 ASF 网站上一张一张勾选 Sentinel-1 数据，单景文件动辄 1~2 GB，浏览器下载动不动就断。断了我又从头点，折腾一个下午，硬盘里多了一堆半截文件，真正能用的没几个。后来我把整套流程改成 curl 查询加 aria2 批量下载，从生成清单到全部落盘，耗时不到原来的十分之一，而且再没出现过中断就要重来的情况。

这篇笔记是写给和我一样从零开始的人：你不一定懂 SAR，也不一定熟悉命令行，但只要跟着下面的步骤走，就能顺利用 aria2 批量下载 ASF 数据。我也会把 ASF 数据的格式和文件结构拆开讲一遍，并分享一套我自己用的记忆法——因为下载到一半发现文件结构看不懂，才是最让人抓狂的事。

1. 从"一次点一个文件"到"一条命令拉完"：下载窘境与选型理由

1.1 手动下载的崩溃日常

我之前的下载流程非常原始：打开 ASF 的检索页面，按时间范围筛选，翻页找到要的区域，逐个勾选影像，然后点下载链接。单景 Sentinel-1 的 SLC 产品普遍 1~2 GB，浏览器的下载管理扛不住这种时长，经常跑到 60% 就报网络错误。

最气人的是浏览器没有完善的断点续传机制。一个文件断了，重新点链接它未必能从断点继续，而是从头开始。30 景数据算下来 45 GB 左右，中途断三四个文件，我的时间就被浪费在反复重试上。更要命的是多文件下载时，浏览器只会按顺序排队，前面一个大文件没下完，后面的全晾着。

后来我意识到，手动流程的核心矛盾是三个：单文件没有多线程加速、下载中断无法稳定恢复、批量排队效率太低。这三件事恰恰是命令行下载工具的主场。

1.2 为什么最后选了 aria2

我其实先试过 wget 和 curl，都能下载，但各有硬伤。wget 有-c断点续传，但单线程跑一个 2 GB 的 TIFF 实在太慢；curl 功能全面，可你要同时拉几十个文件就得自己写循环脚本，循环里还得处理每个下载的退出码和重试，代码量不小。

aria2 的优势正好卡在我的痛点上：

• 多连接下载：-x参数可以让一个文件分成多个连接同时拉，速度提升明显。
• 断点续传：-c配合 .aria2 控制文件，中断后重新执行会从断点继续。
• 多任务并发：-j参数控制同时下载几个文件，不用自己写调度。
• 输入列表批量：-i直接读一个包含所有 URL 的文本文件，适合数据量大的场景。
• 支持自定义请求头：后续访问需要 token 的数据源时，--header能直接带上认证信息。

aria2 的适用面也不局限于 ASF。现在很多提供直链下载的数据平台，比如气象再分析数据、光学遥感影像、开源软件镜像，都可以用同一套方式批量拉取。学一次，后面到处用。

1.3 安装与第一句验证

不同系统的安装方式很常规：

• Debian/Ubuntu：sudo apt install aria2
• CentOS/RHEL：sudo yum install aria2
• macOS：brew install aria2
• Windows：可以用choco install aria2，或者直接去官网下载压缩包

装完先跑aria2c --version确认可用。我习惯先拿一个小文件试一条最简单的命令：

aria2c -x 4 -c https://example.com/test.zip

这一步主要是验证网络和基础参数，避免后面一上来就操作几十个链接，出问题都不知道从哪查。

2. 让 ASF 把数据清单送上门：检索接口与链接提取

2.1 先认识 ASF 这个数据源

ASF 指阿拉斯加卫星设施（Alaska Satellite Facility），是美国一个面向科研的 SAR 数据分发中心，由阿拉斯加大学运营，主要分发 Sentinel-1、ALOS PALSAR、RADARSAT 等卫星数据。其中 Sentinel-1 的数据完整、免费开放，做地表形变、海洋监测、极地研究的人几乎都绕不开它。

ASF 官网提供了一个图形化检索界面叫 Vertex，在地图上框选区域、设置时间，就能看到覆盖范围的影像列表。但图形界面适合人眼筛选，不适合批量操作。你需要的是一个能直接返回结构化结果的接口，也就是 ASF Search API。

我一般在 ASF 官网的 "API" 页面看一下当前的接口说明，不过核心思路一直没变：用参数描述你要的区域和时间，接口返回候选影像的元数据和下载链接。

2.2 用 Search API 按时间和区域找影像

假设我想下载 2023 年 1 月覆盖旧金山湾区某一点的 Sentinel-1 影像，检索命令大致是：

curl "https://api.daac.asf.alaska.edu/services/search/param?platform=SENTINEL-1A&start=2023-01-01T00:00:00Z&end=2023-02-01T00:00:00Z&intersectsWith=POINT(-122.4 37.8)&output=JSON" -o asf_result.json

几个参数拆开看：

• platform：指定卫星平台，比如 SENTINEL-1A 或 SENTINEL-1B。如果想同时搜两个平台，有的接口版本支持逗号分隔。
• start/end：检索的时间范围，使用 ISO 8601 格式的 UTC 时间。
• intersectsWith：空间筛选条件，这里用的是 WKT 格式的经纬度点。也可以换成多边形，格式为POLYGON((-122.5 37.7, -122.3 37.7, -122.3 37.9, -122.5 37.9, -122.5 37.7))。
• output：返回格式，JSON 或 GeoJSON 更适合脚本处理。

如果返回结果太多，接口一般支持&maxResults=100之类的参数限制数量。我第一次用的时候返回了上千条记录，那是最让人懵的——不是数据少不够用，而是数据太多不知道怎么筛。建议先用手头上的研究区边界去限定空间范围，再按时间排序，看看日期分布有没有异常。

搜索结果里每条记录会包含granuleName、platform、startTime、endTime、url等字段。url就是直链下载地址，这正是后面 aria2 需要的东西。

2.3 用 jq 把下载链接筛出来

返回的 JSON 可能很大，不能肉眼去找 URL。我一般用 jq 提取：

jq -r '.features[]?.properties.url // .items[]?.url // .results[]?.url' asf_result.json | grep -E '^https?://' > download_list.txt

这个命令写得稍微有点防御性，因为不同接口版本返回的 JSON 结构不完全一样。有的是 GeoJSON，链接在features[].properties.url；有的是普通 JSON 数组，链接在items[].url或results[].url。实际操作中我都是先jq 'keys'看一眼结构再写提取表达式，很少一次到位。

拿到download_list.txt后，先看开头几行：

head -n 5 download_list.txt

确认链接形态。ASF 的下载地址一般指向.zip或.SAFE，也可能带查询参数。这里要顺带确认一个问题：如果下载需要登录认证，那么链接可能要带 token，或者后面给 aria2 加 Authorization 头。ASF 的元数据检索通常公开，但批量下载有时要求你先有 Earthdata Login 账号，在 ASF 官网按引导生成凭据，否则请求会返回 401。

3. aria2 批量下载落地：我常用的那条命令

3.1 核心命令拆解

数据清单准备好之后，我用的是这样一条命令：

aria2c -c -x 16 -s 16 -j 4 \ --file-allocation=falloc \ -i download_list.txt \ -d /data/sentinel1 \ --log-level=notice \ --log=/data/sentinel1/aria2.log

逐项说明：

• -c：开启断点续传。下载前如果发现同名控制文件，就尝试从断点继续。
• -x 16：每个文件的单服务器最大连接数，也就是把同一个文件切成 16 份用 16 条连接下载。
• -s 16：把文件分成 16 个分片。它和-x经常配套使用，分片数量决定任务的粒度。
• -j 4：同时下载 4 个文件。也就是最高时有 4 个文件，每个文件 16 条连接，整体并发是 64 条连接。
• --file-allocation=falloc：提前分配磁盘空间，避免下载到一半发现空间不足。
• -i download_list.txt：从文本文件读取 URL 列表。
• -d /data/sentinel1：保存目录。
• --log-level=notice --log=...：把运行日志写到文件，方便事后排查。

如果下载链接需要认证，可以追加：

aria2c --header="Authorization: Bearer <TOKEN>"

或者用--http-user、--http-passwd处理基础认证。注意 token 是有时效的，过期后服务器会返回 401，那时不要怀疑 aria2 配置错了，先去重新生成 token 再跑。

3.2 分片与续传的秘密

很多人第一次用 aria2 会好奇：它怎么做到从一个文件的中途继续下载的？其实原理不复杂。-s 16让 aria2 把目标文件在逻辑上切成 16 段，每段对应一个偏移区间，然后分给不同的连接去拉取。下载过程中，aria2 会在同目录生成一个隐藏的.aria2控制文件，里面记录了每个分片已经下载到什么位置。下次运行加-c，它读控制文件就知道哪些片段已完成、哪些片段要继续。

所以有一个关键习惯：不要随手删除.aria2文件。我见过有人觉得磁盘里有隐藏文件很碍眼，批量清理时一起删了，结果再跑-c时 aria2 无法续传，只能从头下载。看到这些控制文件，正确的反应是"幸好它还在"。

另外，--file-allocation=falloc在 Linux 下会瞬间预占空间，配合断点续传非常稳。macOS 下可以改用--file-allocation=trunc，Windows 用默认的 none 也没太大问题。

3.3 并发参数是不是越大越好

不是。这是我最早踩过的一个认知坑。我一开始以为把-x开到 64、-j开到 16，速度就能一路狂飙，结果 ASF 服务器直接返回一堆 403，甚至连接被重置，下载速度反而归零。

服务端永远有连接数限制和带宽配额，过高的并发只会触发保护策略。根据我的实测，这几个参数落在下面的区间最稳：

如果发现日志里频繁出现 429、403、connection reset，第一反应不是加并发，而是减并发。把-x降到 8、-j降到 2，通常问题就消失了。此外，如果你这台机器还在跑别的业务，用--max-overall-download-limit=50M之类参数限个速，避免占满出口带宽。

3.4 丢到后台让它自己跑

命令行任务最怕断网、关终端导致中断。我一般用 nohup 把 aria2 放到后台运行：

nohup aria2c -c -x 16 -s 16 -j 4 \ -i download_list.txt -d /data/sentinel1 \ --log-level=notice --log=/data/sentinel1/aria2.log \ > /data/sentinel1/nohup.out 2>&1 &

nohup让进程不会因为终端退出而被杀掉，配合日志文件，可以随时回来看下载进度。我在服务器上更推荐用 tmux 或 screen，开一个持续存在的会话窗口运行命令，想看实时输出还能切回去。

观察进度我常用两个命令：

tail -f /data/sentinel1/aria2.log du -sh /data/sentinel1

日志会逐行显示每个文件的下载进度、速度和百分比；du看目录总大小，心里大致有数还剩多少。整个任务跑完后，再顺手搜一下日志里的ERROR，确认没有漏网之鱼。

4. 打开下载结果：ASF 数据的格式与文件结构记忆法

4.1 文件名本身就是完整说明书

下载完成后，你会看到类似这样的文件名：

S1A_IW_SLC__1SDV_20230124T021850_20230124T021917_046799_05A7F6_AB32.SAFE.zip

这名字乍看像乱码，其实是把关键元数据全部拼在文件名里了。我拆成六段来记：

记这个文件名有个窍门：把整串从中间拆开，前半是"谁拍的、什么模式、什么级别、什么极化"，后半是"哪段时间、哪个轨道、哪个片段、哪个唯一编号"。任何时候拿到一个文件，先朗读一遍这六段，你就知道这份数据大概是什么。

4.2 解压之后看目录：SAFE 的固定骨架

下载的 zip 包解压后会得到一个.SAFE目录。SAFE 是欧洲空间标准的归档格式，指的是标准存档格式（Standard Archive Format for Europe）。整个目录的内部结构高度固定，核心骨架长这样：

S1A_IW_SLC__1SDV_20230124T021850_*.SAFE/ ├── manifest.safe ├── annotation/ │ ├── s1a-iw1-slc-vv-20230124t021850-*.xml │ ├── s1a-iw2-slc-vv-*.xml │ ├── calib/ │ └── noise/ ├── measurement/ │ ├── s1a-iw1-slc-vv-*.tiff │ ├── s1a-iw2-slc-vv-*.tiff │ └── s1a-iw3-slc-vv-*.tiff ├── support/ │ ├── dem/ │ └── gcp/ └── preview/

各层的作用：

• manifest.safe：整个目录的起点。它记录了数据的产品版本、处理软件、时间引用、文件列表，相当于档案的目录卡。
• annotation/：存放 XML 格式的注解文件，描述每个波束的成像参数、极化信息、多普勒参数，还有calib（校准）、noise（噪声）等子目录。
• measurement/：图像数据本体，通常是一个个巨大的 GeoTIFF 文件，例如s1a-iw1-slc-vv-*.tiff。这是后续处理的直接输入。
• support/：辅助数据，如 DEM、GCP 地面控制点，用于几何校正和正射处理。
• preview/：预览影像，用于快速浏览，占用空间不大。

4.3 三层记忆法："先看清单，再看说明，最后拿数据"

为了不把结构记乱，我用了一个生活化类比：把一个.SAFE目录想象成一盒包装好的饼干。

• manifest.safe是包装箱外面的配料表和产品说明。拿到任何数据，第一件事应该是打开它，确认产品有效、文件齐全，后续软件也是从这里开始读取。
• annotation/是随饼干附赠的烘焙说明或营养成分表，告诉你这份数据"是怎么做出来的"、用了哪些算法和校正。
• measurement/是饼干本身，是你真正要吃的东西，对应的就是那几块巨大的 TIFF 影像。
• support/像是盒子里的防震纸板，不直接参与吃，但保证了产品的稳定和正确性。
• preview/是盒子封面上的效果图，让你不打开盒子也能知道大概长相。

所以整套操作顺序我记成一句话：先看清单（manifest），再看说明（annotation），最后拿数据（measurement）。每次拿到一批新数据，我都按这个顺序做一次快速巡检，基本不会漏掉关键信息。

4.4 快速体检命令

解压后不要急着分析，先跑几个命令确认文件结构完整：

ls -lh *.SAFE/ du -sh *.SAFE

如果安装了 GDAL，可以看一眼 TIFF 基础信息：

gdalinfo *.SAFE/measurement/*.tiff | head -n 20

gdalinfo能输出影像尺寸、投影信息、像素类型等，凡是报错说"找不到投影""尺寸异常"的，基本可以判定数据不完整。注意，处理软件（SNAP、GAMMA、ISCE 等）都要求保持.SAFE目录的完整结构，不要为了"看起来清爽"把 TIFF 单独移出来，否则后续读取时找不到配套 annotation 文件，你会被各种神秘报错折磨。

5. 下载后的检查、清理与踩坑清单

5.1 下载完成不等于能用

aria2 显示 100% 只代表文件按字节数下载完毕，不代表内容可用。网络波动、磁盘写入异常、服务器返回错误内容等情况，都可能让最终文件损坏。我的检查习惯是三步：

先看日志。grep "ERROR" /data/sentinel1/aria2.log，确认没有报错项。如果有，把对应 URL 单独提取出来重新下载。

再看目录。.SAFE目录是否包含manifest.safe、annotation/、measurement/这些必备内容。如果下载的是 zip，先unzip -t测试一下完整性，或者用sha256sum和服务器提供的校验值比对。

最后抽查 TIFF。gdalinfo能正常读完，说明文件头没有截断，基本可用了。遇到尺寸异常、元数据缺失的，直接标记重下，不要心疼那点带宽。

5.2 我踩过的几个坑

第一坑：并发开太高被 403。这个前面说过，解决办法是降并发而不是加并发。ASF 是公共服务，有配额保护，像 64 并发还带 32 分片这种配置，几乎必然触发限流。

第二坑：磁盘空间没有预留两倍。一个 1.5 GB 的 zip，解压成.SAFE目录后体积会明显膨胀，加上 aria2 下载时的临时分片，实际占用可能到压缩包的 1.5~2 倍。我习惯先df -h确认空间，再算总需求，否则下到一半磁盘满，报错很容易让人误以为是网络问题。

第三坑：删了.aria2控制文件。再次强调，.aria2文件是断点续传的命根子。只要任务还没确认完成，就不要清理它们。

第四坑：从浏览器复制下载链接丢给 aria2。浏览器地址栏里的链接可能带了会话参数，或登录态，复制给命令行工具后根本拉不动。正确做法是从 API 响应的url字段提取直链，既干净又统一。

第五坑：token 过期。有些数据源的下载链接要带 Authorization 头，token 有有效期。批量任务跑了一半报 401，不是 aria2 坏了，是凭据失效了，重新生成 token 续跑就行，已经下载完成的部分不会浪费。

5.3 归档与命名习惯

下载完成后，我从来不把文件直接丢在一起。我的目录结构一般是：

/data/sentinel1/ 2023/ 046799/ S1A_IW_SLC__1SDV_20230124T021850_*.SAFE/ 046801/ S1A_IW_SLC__1SDV_20230126T021852_*.SAFE/

按年份再按绝对轨道号分目录，好处是同一轨道的时序数据天然挨在一起，后续做干涉堆叠（InSAR stack）时找数据非常快。另外，我会把检索时导出的元数据 CSV、download_list.txt、aria2 日志全部复制一份放在项目目录下，将来倒退实验时还能知道这批数据是谁、什么时候、用什么条件检索出来的。

整理的时候可以把preview/目录下的图片单独抽出来，做一张 Quick Look 速览表，挑选数据时不用挨个打开大 TIFF，扫一眼缩略图就能判断云盖、噪声情况。这个习惯帮我省了大量时间。

最后说点个人体会。当初我为了批量下载 ASF 数据折腾了一整个下午，现在回头看不外乎两件事：从 API 拿到干净的直链，再让 aria2 把多线程、断点续传、任务并发管理起来。这套思路完全可以迁移到其他任何提供直链的数据源，气象数据、光学遥感影像、开源镜像，都是一个套路。最后再分享一个小技巧：如果下载列表里既有 zip 也有.SAFE目录形式，我建议优先下载 zip 版本，因为大量小文件目录在批量拉取时不仅更慢，还会吃掉大量磁盘 inode，后续管理和传输都麻烦。希望这篇笔记能帮你少走点弯路，顺利把数据拉到手。