Argo 全球剖面浮标库 — 两千个浮子，四百万条剖面

Argo 把海洋测成了一张会自己移动的网。两千多个浮标沉在海里，各自漂、各自潜、各自冒上来发报，没有一座塔、一根缆、一个固定坐标。它给出的不是「某地点的时间序列」，而是「某浮标在它自己走过的地方留下的断面」。

这份条目讲的是 GDAC 这一个出口——国际 Argo 计划的中央数据汇编中心，由多个国家的数据中心分工处理后汇入的目录。它不是 Argo 计划的项目主页，不是浮标实时监控面板，也不是近地面的再分析产品。它只有一件事：把每颗浮标测到的东西，一个浮标一档地摆出来。

它同时是海洋机器学习里最常用、也最容易被当成「规则网格」误用的原位观测。下面先给一屏速览。

项目	数值	来源
官方全名	Argo Global Data Assembly Center (GDAC) 浮标剖面集合	镜像目录根节点名称
组织方	国际 Argo 计划，各 DAC 分工	目录内的 11 个一级子目录
数据中心（DAC）	11 个	镜像目录逐个数
浮标目录数	22,080	逐 DAC 清点后求和
时间起点	1997 年 7 月（最早的那批剖面）	单个浮标文件的剖面时刻
采样深度	自表层至约 2000 米	浮标设计深度；单个剖面未必到达
核心要素	压力、温度、盐度	文件的 STATION_PARAMETERS 字段
文件格式	NetCDF，Argo 格式 3.1 / 手册 1.2	文件内 FORMAT_VERSION
单剖面文件变量数	58 个	抽取文件的变量计数
更新	持续追加，实时流与延时流并行	目录内文件时间戳
许可	开放访问，须注明来源并引用；无 SPDX	无文件内 license 字段；官方承诺
访问门槛	无注册，HTTP 直取或 OPeNDAP	镜像目录可直接列出

§1 速览：它是什么，也不是什么

1.1 一句话定义

Argo GDAC 是一份按浮标归档的海洋断面观测集合：每颗漂流浮标是一个独立的数据源，它每十天左右下沉到两千米、再升上来，沿途把压力、温度、盐度逐米记下，浮出水面后经卫星把整条剖面传回，落进它所属的数据中心目录，再由 GDAC 汇总成一个可遍历的树。

这句话里每个词都在承重。「按浮标」决定了目录的形状，「每十天」决定了时间轴的粗糙程度，「下沉再升上」决定了剖面的空间含义，「逐米」决定了数据量，「传回落盘」决定了延迟。

1.2 三个常见的错认

第一个错认：把它当作一片覆盖全球的观测场。它不覆盖任何东西。某一片海在某个时刻有没有数据，取决于当时有没有浮标恰好漂过去。赤道、南大洋、北大西洋的密度远高于边缘海、半封闭海与极区冰下。它不是网格，是散点，而且是不均匀、会移动、会消失的散点。

第二个错认：把它当作「一条剖面上的每个深度都有值」。剖面上的层是采样得到的，仪器在上升过程中按固定节律记录，记录点位随深度变化而略有不齐。同一个浮标的不同剖面，层数可以差出好几倍。

第三个错认：把它当作一份定稿的档案。实时流是自动化处理的，延时流是人工校正的，两条流并行存在，同一条剖面在两处可能给出不一样的值，而且延时的到达时间没有承诺。

1.3 三十秒决策卡

你的处境	它能否帮你
要建 0–2000 米的水柱结构模型（温跃层、混合层、次表层极值）	能，这是它唯一胜任的领域
要算海洋热含量或做 ENSO 的次表层信号	能，但必须处理采样偏倚与空间不均匀
要补卫星只能看到表层那几米的信息	能，且是跨洋盆唯一的常规来源
要研究某一固定点的季节循环	不能，浮标不会停在原地
要研究近岸、海湾、河口	不能，它主要在大洋
要一份可以直接喂进卷积网络的规则三维场	不能，须先自己做插值或分箱，而这步本身就是一个研究问题
要一份时间上等间隔、样本独立的时间序列	不能，间隔在十天上下浮动，同一浮标的剖面高度相关

1.4 不适合谁

如果需求是**「某地某月的温盐是多少」**，这份集合不会直接回答。它记录的是浮标去过的地方，不是任何选定的地点。要得到地点口径的答案，得先选一套插值或客观分析方案，把散点变成场——那时用的已经是别人的二次产品，不是这份档案本身。

如果需求是样本独立，也不合适。同一浮标的相邻剖面在物理上连续，在时间上只隔十天，在水文结构上共享同一团水体。把整库剖面打乱切分训练集与测试集，同一浮标的同一段漂流可能同时落进两边，这是典型的泄漏。切分必须按浮标分组。

如果需求是**「最近一周的海洋状况」**，要小心。最近一段时间的剖面多数还是实时版本，未经人工校正的盐度可能存在系统性漂移。想知道某条剖面「成色」如何，得看 DATA_MODE 与质控标记，而不是看它新不新。

1.5 贯穿本文的案例：13857 号浮标与它的第 140 条剖面

1997 年 7 月 19 日 14 时 55 分，一颗型号为 PALACE 的浮标在热带大西洋入水，编号 13857，由美国国家海洋与大气管理局的一位研究员负责，挂靠在「大西洋环流与气候实验」（ACCE）项目下。它属于最早的一批剖面浮标之一，那时候 Argo 这个计划还没有正式成形，浮标的任务也很简单：测温度，测压力。

这颗浮标一共工作了四年多。它留下了 140 条剖面，最后一条在 2001 年 10 月 5 日。整段漂流从北纬 0.27 度、西经 16.03 度出发，最后停在北纬 5.15 度、西经 24.43 度，直线距离约 1079 公里，实际路径累计约 7252 公里。它没有测量盐度——目录里这类只测温压的浮标另有去处。

选它作为贯穿案例，不是因为它特殊，恰恰是因为它把这份集合的几个关键性质压缩在了一个二十多兆字节的目录里：一标一档的目录形状，只有延时版本没有实时版本的文件分布，缺测值用 99999 而不是 NaN 的写法，延时校正记录里那句「这台浮标的压力传感器会在水面自动归零，因此在延时质控中无需再加校正」的原话，以及 140 条剖面里只有 4 条的层数少于五十层这一采样不均的事实。

后文每次提到「§1.5 的案例」，指的都是它。

§2 数据构成：一浮标一档，把时间折进文件里

2.1 目录的形状

打开镜像的根目录，看到的是十一个一级子目录，名字都是三个到七个字母的缩写。它们是国家或机构数据中心（Data Assembly Center，DAC）的代号。每个目录下面挂着一串以数字命名的子目录，一个数字对应一颗浮标。

逐个数下来是这些：

DAC 代号	浮标目录数	归属
aoml	9,991	美国大西洋海洋与气象实验室
coriolis	4,312	法国海洋开发研究院（Ifremer）
jma	2,059	日本气象厅
csiro	1,289	澳大利亚联邦科学与工业研究组织
bodc	990	英国海洋数据中心
meds	765	加拿大海洋环境数据中心
incois	640	印度国家海洋信息服务中心
csio	602	中国海洋大学相关中心
kma	274	韩国气象厅
kiost	135	韩国海洋科学技术院
nmdis	19	中国国家海洋信息中心
合计	22,080	十一个 DAC 相加

这张表里最值得注意的不是总量，是分布的形状。最大的一个 DAC 占了 45%，前三个加起来占了 74%。也就是说，这份集合的「背景」高度偏向几个特定机构的浮标投放策略与海域选择，不是均匀分摊的全球合作。当你按 DAC 分层抽样时，实际上是在按「谁投的、投在哪」分层。

第二个值得注意的地方是，这个数是个浮标目录数，不是剖面数，也不是在用浮标数。目录里包含大量早已失联的历史浮标——§1.5 的案例在 2001 年就停了，但它的目录一直挂着，靠的最后修改时间停在它最后一条剖面被处理的那一刻。想知道「现在有多少颗在跑」，这个数字回答不了。

2.2 一个浮标目录里有什么

进入任意一个浮标目录，看到的是四类文件加一个子目录：

文件名	内容	单文件量级
<编号>_meta.nc	浮标的身份与履历：型号、制造商、序列号、投放时间地点、传感器清单、标定方程	几十 KB
<编号>_prof.nc	该浮标全部剖面的汇总（多剖面版本）	与剖面数成正比
<编号>_Rtraj.nc	沿时间的轨迹记录，含每一条卫星定位	数百 KB
<编号>_tech.nc	技术参数随时间的记录	百 KB 量级
profiles/ 子目录	单剖面文件，一条剖面一个文件	十几 KB 到几十 KB

「一浮标一档」这句话的重点在第四行和第五行之间的关系。profiles/ 下的单剖面文件和标目录下的 _prof.nc 汇总文件是同一批剖面的两种组织方式：前者适合只取一条剖面，后者适合一次读全。真正需要理解的是——一个测量剖面的物理单位，在磁盘上对应的是一个目录，不是一行记录。

以 §1.5 的案例为例：profiles/ 下有 140 个 .nc 文件，从 D13857_001.nc 一路到 D13857_140.nc，全部以 D 开头。汇总文件 13857_prof.nc 的 N_PROF 维度正好是 140，N_LEVELS 是 113。也就是说，读 140 个文件与读 1 个文件的 140 层，得到的是同一批数据，但前者要发 140 次请求。

2.3 三种文件的分工

文件	维度性质	变量数	回答什么问题
meta	每标一个，无时间维度	65	这是谁，谁造的，什么时候下水，装了哪些传感器
prof	剖面 × 层	58	这条剖面在每个深度上是什么值
Rtraj	定位点 × 时间	97	浮标曾经出现在哪里，在哪两个点之间没人知道

三者的变量数差别不是设计的选择，是内容的必然。meta 要把传感器、标定、配置全部展开成字符串数组，所以变量多而记录少；prof 的核心只有几列数值，但每条剖面占一层；Rtraj 要把每个卫星定位的误差椭圆、时间状态、压力归属都记下来，所以变量最多。

这张表还藏着一个常被忽略的事实：轨迹文件里的定位点远比剖面多。§1.5 的案例有 140 条剖面，轨迹文件里却有 3028 个定位点——平均每条剖面之间还有二十几个定位。这说明浮标在两次上浮之间并非完全失联，只是不传科学数据。这条线索对理解「位置」的性质很关键，§3 会展开。

2.4 单个剖面文件里的字段

一份典型的剖面文件有 58 个变量。把它们按用途分组，比逐列罗列更好理解：

组	代表字段	作用
身份	PLATFORM_NUMBER、CYCLE_NUMBER、DIRECTION	这是哪颗标、第几次、上升还是下降
时刻与位置	JULD、JULD_LOCATION、LATITUDE、LONGITUDE	什么时候、在哪儿浮出来的
观测值	PRES、TEMP、PSAL	每一层测到的原始值
校正值	PRES_ADJUSTED、TEMP_ADJUSTED、PSAL_ADJUSTED	延时质控后的对应值
误差	*_ADJUSTED_ERROR	校正的不确定度
逐层质控	PRES_QC、TEMP_QC、PSAL_QC、*_ADJUSTED_QC	每个数值的可信度标记
整条质控	PROFILE_TEMP_QC 等	整条剖面的概括判断
状态	DATA_MODE、DATA_STATE_INDICATOR	实时还是延时、数据是否完整
历史	HISTORY_ACTION、HISTORY_INSTITUTION、HISTORY_DATE、HISTORY_QCTEST	每一次改动谁做的、做了什么、什么时候
标定	SCIENTIFIC_CALIB_EQUATION、SCIENTIFIC_CALIB_COEFFICIENT、SCIENTIFIC_CALIB_COMMENT	校正用的方程、系数与说明文字

最后一行那一组的价值远超它的篇幅。「原始值不被覆盖、校正值另立一列」这一设计，让文件和它的修订史同时存在。一份被反复校正的剖面，可以在 HISTORY 里看到全部修订动作，在校正说明里读到操作者对这台仪器的判断。

§1.5 的案例正好给出了一个干净的样板。它的第 140 条剖面里，TEMP_ADJUSTED 整列都是 99999，而 TEMP 是有值的；PRES_ADJUSTED 与 PRES 则逐层完全相等。三处信息拼起来是同一个意思：这条剖面的压力不需要校正，温度没有可用的延时校正值，只有原始值。如果不看这几列的关系，直接取后缀带 ADJUSTED 的变量，前 17 层全部会变成缺测。

同一份文件的校正说明写得更直白：

SOLO-W floats auto-correct mild pressure drift by zeroing the pressure sensor while on the surface. Additional correction was unnecessary in DMQC; PRES_ADJ_ERR: SBE sensor accuracy + resolution

换成中文是：这类浮标会在浮出水面时自动把压力传感器归零，从而自行修正轻微的压力漂移；因此在延时质控中不需要额外校正；误差一栏取的是传感器的标称精度加分辩率。对应的 PRES_ADJUSTED_ERROR 是每层 2.4 分巴，TEMP_ADJUSTED_ERROR 是 99999——因为没有做校正，也就不必给校正误差。

这一段话是整个集合的缩影：「延时质控」不等于「数值变了」，它可能只是「确认了不需要变」，而这两件事在数据上长得完全不一样。

2.5 规模的三个口径

关于规模，可以听到三种说法，它们指的并不是同一件事：

口径	量	来源性质
浮标目录数	两万余	§2.1 逐项清点
历史浮标总数（含已停用）	与上一项同量级	公开材料常用「两万余个」
剖面数	四百万量级	公开口径的表述，非目录可数

前两项来自同一次清点：目录就是浮标的清单，挂着的都是历史上投过的。第三项不能从目录直接读出，因为目录层级只到「一标一目录」，剖面的条数要到每个标目录里逐个数文件，或者读汇总文件的 N_PROF 维度。这一次没有做逐标清点，所以正文不给精确剖面数。

还有一个更少被提起的口径：在跑浮标数。任意时刻真正在采样的只是历史总数的一小部分——换电池、失联、回收、损坏都会让一颗标退出。浮标设计寿命通常是数年，靠锂电池供电。这意味着二十多万层剖面里，绝大多数是「过去的」，要研究当下，得按时间窗筛，而不是按浮标筛。

§3 定位层：移动的平台，插值的起点

3.1 主键只有一对

整个集合里，唯一定位一条观测记录的只有两个字段的组合：浮标编号加循环序号。PLATFORM_NUMBER 与 CYCLE_NUMBER 一起，才唯一指定一条剖面。单独一个浮标编号只指定一个文件，单独一个循环序号只指定「某标第几次」。

这两个字段的形状都值得说明。浮标编号是八字符，按「字母加三位数据中心代号加五位流水号」的规则组织。所以它不只是流水号，它把归属也编进去了——看到前四位，就知道这颗标最初归谁管。循环序号是这颗标自己的计数器，从 1 开始，0 留给入水循环。

由此引出的第一个陷阱：循环序号不是时间，也不是全局序号。两个不同的浮标都有第 50 条剖面，它们毫无关系。把全库剖面按循环序号排序，得到的是一个毫无意义的混合序列。要按时间排，必须用 JULD。

3.2 位置只说明浮出水面时在哪

一条剖面的位置，在文件里只有一对经纬度。这一对是卫星定位给出的——浮标浮出水面后，卫星系统才发现它在哪，并把整段剖面数据一起取走。

那么，这条剖面的「起点」在哪？答案是：不知道。文件里没有下潜点的独立字段。数据使用者能拿到的，是上一浮出点的位置和这一浮出点的位置，然后按时间在两者之间插一条直线或按速度估计。这就是所谓「插值起点」。

这个差别有多大，看 §1.5 的案例就够了。它的 140 条剖面，相邻两点的连线平均 52 公里，最长的一段 224 公里。浮标下沉、停留、上升，全程大约十天，洋流带着它漂过几十甚至上百公里。真实的路线是一条弯曲的三维曲线，文件里给的是两个端点。如果你要研究的是水平输送、水团路径、或浮标漂移模拟，只用端点会丢掉绝大部分信息。

更麻烦的是上升与下降的时间差。同一循环，从水面到两千米再回到水面，通常要几个小时。文件里的 JULD 是整条剖面的时间标记，不是逐层时间。也就是说，一条剖面内部，各层的观测时刻并不相同，而且没有任何字段记录这个差异。对于十天尺度的海洋，这个误差通常可容忍；对于与天气、潮汐、日变化耦合的问题，它就是决定性的。

3.3 三层位置精度的差别

集合里关于位置的时间信息，其实分三层：

层	字段	精度含义
定位时刻	LATITUDE、LONGITUDE 对应的时刻即 JULD	上浮完成、数据开始回传的时刻
定位时刻（另记）	JULD_LOCATION	与 JULD 相差数分钟到数小时，见下
上升、下降起止	JULD_ASCENT_START、JULD_ASCENT_END 等	仅轨迹文件中有，给出整段剖面的时间跨度

JULD 与 JULD_LOCATION 的差，是同一个东西的两个时间戳。前者是剖面本身的时刻标记，后者是定位发生的时刻，两者在 §1.5 的案例里相差约 362 秒。这六分钟看起来无关紧要，但它说明「剖面的位置」和「剖面的时间」在系统里是两个独立的量，并不是一个时空点。

轨迹文件里那几个上升起止字段，才是把剖面从「一个点」变成「一个时间段」的关键。它们给出的信息是：这条剖面从几点几分开始上升，到几点几分浮出。拿这个跨度除以深度层数，就得到每层的时间间隔。这是一个可以自己补出来的信息，但必须主动去补。

3.4 灰色名单：只有温度没有盐度的浮标

不是每颗浮标都测盐度。早期的浮标只能测温度和压力；某些型号因传感器故障或设计限制，只发温度和压力。这类浮标的数据不进入核心 Argo 的标准剖面集，而是被列进一份单独的名录。

§1.5 的案例就是其中之一。它的传感器清单里只有两项：CTD_TEMP 和 CTD_PRES。参数清单里也只有 TEMP 和 PRES，没有 PSAL。它的数据是有效的，能进入温压场分析，但无法参与盐度计算，也无法参与依赖盐度的密度、层结、声速等派生量。

这个边界在用数据时必须先确认。判断方法很简单：读 STATION_PARAMETERS 字段，看有没有 PSAL。若没有，这条剖面在盐度相关的任务里必须排除，否则会在聚合时引入一片缺测而非「无此测量」的空白，两种空白在统计上完全不同。

3.5 混合模式：同一个文件里两套世界

DATA_MODE 是个单字符。三个取值：R、A、D。看起来简单的三值，实际含义是「这个文件里有哪些值是延时处理过的」。

取值	含义	读法
R	全部为实时	无任何人工校正
A	全部为延时	整文件已完成质控
D	混合	部分剖面延时、部分实时，或同一条剖面里部分要素延时

最容易踩的是 D。看到 D 很容易理解成「延迟模式」，但它的实际含义比这更细：它只承诺「这个文件里有延时值」，不承诺「哪一条、哪个要素」。§1.5 的案例的汇总文件 13857_prof.nc 的 DATA_MODE 是 140 个字符全 D，说明 140 条剖面都完成了延时处理——这时 D 与 A 的差别只是历史遗留：格式这样做是为了兼容同一文件里混装的情形。

判断某一条剖面到底有没有完成延时处理，靠的是这一条的 DATA_MODE 字符，不是文件的汇总值。判断某个具体数值是否被校正过，靠的是 *_ADJUSTED_QC 这一列，不是整条的状态。

§4 质量层：实时与延时，两条并行而不等价的路

4.1 两条流的时间差

Argo 的设计里，一颗浮标测完一条剖面、传回数据中心后，会立刻发布一版自动处理过的数据。这一版叫实时模式。同时，这条剖面会进入一个等待人工审阅的队列，由数据中心的海洋学家定期处理——检查盐度漂移、检查温度偏差、检查压力漂移、给每个数值打质控标记，然后发布延时模式版本。

两条流并行存在，同一条剖面可能同时有实时版和延时版。延时版的时间通常比实时版晚数个月到一年多，而且没有承诺——什么时候能完成，取决于对应 DAC 的人手与排期。

这个时间差对使用的影响非常大，值得单列：

用途	建议用哪条	理由
短期海洋状况监测	实时	延时版不存在
长期气候分析、海洋热含量	延时	实时版的系统性偏差会累积进趋势
盐度相关的密度、层结计算	延时	盐度漂移是实时版最主要的问题
训练模型	延时（若可得），否则实时并显式标注	混用会教模型把「版本差」学成「信号」
检验数据同化系统	实时	同化本身用的就是实时流

「延时版一定更准」这句话也不是无条件成立。延时质控是人工判断，也有人为判断失误、修正过度、或干脆没有足够信息而只能放过的情形。HISTORY 与 SCIENTIFIC_CALIB_COMMENT 字段就是留给审阅者写理由的。§1.5 的案例里，那句话明确说「不需要额外校正」，这是延时质控的结论，不是没有做。

4.2 原始值与校正值为什么必须同时留

很多数据产品在更新时直接覆盖旧值，使用者只看得到最新一版。Argo 不是这样。它把原始值与校正值作为两组独立的变量放在同一文件里，谁也不覆盖谁。

这个设计在数据工程上不算优雅——它让文件体积近乎翻倍，让每个读取者都必须选择取哪一组。它的价值在于两件事：

第一，校正可以被审查。任何人都能算出「延时版比实时版改了多少」，并把改动归因到某个具体的质控动作上。§1.5 的案例里压力两列逐层相等，这本身就是一个可验证的结论。

第二，校正可以被建模。原始值与校正值的差，是人工判断的目标变量。这正是「学习如何做质控」这类研究的天然训练集——输入是原始值、相邻剖面、浮标元数据，输出是校正量。没有这个配对结构，这个任务根本无法构造。

但它也是一个巨大陷阱：如果代码只写了 TEMP 而没写 TEMP_ADJUSTED，你不会看到任何报错，只会得到一份没校正过的数据。反过来，如果只写 TEMP_ADJUSTED，你会得到一份有大量缺测的剖面集——§1.5 的案例第 140 条剖面前 17 层全是 99999。两份都不会报错，都不会提示，只有下游的结论会不同。

4.3 质控标记怎么读

每个观测值都带一个字符质控标记，1 到 9 不等。常用的几个：

标记	含义	处理建议
1	良好	直接用
2	可能良好	通常可用，但需注意
3	可能有问题	谨慎使用
4	有问题	排除
5	值被修改	用校正列，不用原始列
8	估计值（由邻近值插出）	视场景决定
9	缺测	排除

§1.5 的案例第 140 条剖面，TEMP 的逐层标记全是 4，而整条剖面的概括标记 PROFILE_TEMP_QC 是 F。也就是说，这条剖面的温度在质控中被判有问题，但原始值仍然留在文件里，让使用者自己决定要不要用。这与「缺测」不是一回事——缺测是真的没有测，标记为 4 的是测了但有问题。

这里有一个与直觉相反的细节：质控标记为 4 的数值并不是 NaN，它就是一个正常的浮点数。读取时如果不检查标记，任何统计都会把它算进去。

4.4 缺测怎么表示

这是最容易让新人栽跟头的一点。Argo 的数值字段用填充值 99999 表示缺测，而不是 IEEE 的 NaN。用 NetCDF 的高级库读出来时，库会按属性自动把填充值转成掩码，但那是库的善意，不是文件的事实。用最底层的读取方式，看到的会是 99999.0 这个正常的浮点数。

用 §1.5 的案例算一笔账：140 条剖面乘以 113 层，等于 15,820 个温度槽位。其中 1665 个是 99999，也就是约一成的槽位没有温度值。这些缺测不是随机分布的，它们密集地出现在少数几条浅层数极少的剖面里——140 条里有 4 条的层数少于五十层，最少的一条只有 13 层。这些多半是浮标遇到问题时的勉强回传。

如果把 99999 当成真实温度参与平均，结果会被拉高到荒谬的地步。99999 度这个数出现在任何一个统计里都会立刻暴露，但若先做了归一化、标准化、或差分，「荒谬」就被抹平了，只剩下一个逐渐传播的偏差。

4.5 层数不均：不是每一列都一样长

同一颗浮标的不同剖面，层数差异可能很大。同一个剖面维度上，有的层数 113，有的层数 13。这在 NetCDF 里表现为一个二维数组，短剖面的尾部用填充值补齐。

这意味着两件事。第一，任何按层索引的操作都必须先检查该层是否有效。第二，按「层号」跨剖面比较深度是没有意义的——第 1 层在一条剖面里可能是 11.9 分巴，在另一条里可能是 5 分巴。要比深度，必须先按压力重采样。

§1.5 的案例里，第一条剖面的前几层是 11.9、17.0、22.1、27.2、32.3 分巴，层距约 5.1 分巴；第 140 条剖面前几层是 874.7、884.9、895.0 分巴，层距约 10.2 分巴。同一颗标，早年与晚年的采样节律都不同。

§5 工具层：怎么取、怎么读、怎么验

5.1 入口的现状

Argo 计划的几个主要入口，在不同网络环境下的可达性差别很大。本次核验的结果是：官方的项目主页、法国的原始镜像、以及给出总 DOI 的期刊式仓储站点，在本环境中连接全部超时；美国国家环境信息中心（NCEI）维护的 GDAC 镜像可以完整访问，从根目录一路下钻到单个文件都没有障碍。

这条镜像同时提供两种取数方式：直接下载整文件，或者用 OPeNDAP 只取需要的变量与切片。两种方式的路径前缀不同，一个用 fileServer，一个用 dodsC，后面接同样的相对路径。OPeNDAP 的好处是取一条剖面的一条变量不需要下载整个文件，坏处是每个切片一次请求，批量取数会变成请求风暴。

还有一个平行目录，内容与 GDAC 相同但组织方式不同。它不是按浮标分，而是按海盆（大西洋、太平洋、印度洋）加年月日分，文件名带一个 nodc_ 前缀。这个目录里是一条剖面一个文件，适合按时间窗批量取用。它被描述为「在原始文件基础上补充了发现元数据」的版本，科学内容与质控标记保持原样。

5.2 一条命令取一份浮标

以 §1.5 的案例为例，取它的元数据：

curl -sSL -o 13857_meta.nc \
  "https://data.nodc.noaa.gov/thredds/fileServer/argo/gdac/aoml/13857/13857_meta.nc"
curl -sSL -o 13857_prof.nc \
  "https://data.nodc.noaa.gov/thredds/fileServer/argo/gdac/aoml/13857/13857_prof.nc"

路径的构造遵循「DAC 代号 / 浮标编号 / 文件名」三层，没有更复杂的约定。整个集合的路径规则就是这一条，记住它就可以遍历全部。

5.3 用 OPeNDAP 只看变量清单

在下载任何数据之前，先看一份文件的变量与属性清单，是一个省钱的做法：

curl -sSL "https://data.nodc.noaa.gov/thredds/dodsC/argo/gdac/aoml/13857/13857_prof.nc.das"

返回的是属性描述，可以看到全局属性里的 Conventions = Argo-3.1 CF-1.6、featureType = trajectoryProfile，以及每个变量的 long_name、units、valid_min、valid_max、_FillValue。剖面文件的全局属性很精简，只有七条：标题、机构、来源、历史、参考、手册版本、约定。里面没有 license 字段，这一点很重要，下文 §7 会再提。

5.4 读一份剖面并正确处理缺测

下面的代码把 §1.5 的案例读进来，并按质控标记与填充值筛掉不可用的层：

import numpy as np
from scipy.io import netcdf_file

with netcdf_file("13857_prof.nc", "r", mmap=False) as f:
    v = f.variables
    cycle = v["CYCLE_NUMBER"][:].astype("int32")
    juld = v["JULD"][:].astype("float64")
    pres = v["PRES"][:].astype("float32")
    temp = v["TEMP"][:].astype("float32")
    temp_qc = v["TEMP_QC"][:]
    lat = v["LATITUDE"][:].astype("float64")
    lon = v["LONGITUDE"][:].astype("float64")

FILL = 99999.0
bad = (temp >= FILL) | (temp <= -FILL)
bad |= np.isin(temp_qc, [b"4", b"9"])
temp = np.ma.masked_array(temp, bad)

n_prof, n_lev = pres.shape
print("剖面数", n_prof, "层数", n_lev)
for i in (0, n_prof - 1):
    ok = ~temp.mask[i]
    print(cycle[i], lat[i], lon[i], "有效层", ok.sum(),
          "顶层压力", pres[i, 0] if ok.any() else None)

在 §1.5 的案例上跑出来的结果是：剖面数 140、层数 113；第 1 圈在北纬 0.267 度西经 16.032 度，第 140 圈在北纬 5.149 度西经 24.432 度。这两对坐标是各自上浮时的位置，中间那 139 段发生了什么，文件里没有。

这段代码里有两处值得单独指出。一处是填充值的双重判据：既判大于等于 99999，也判小于等于 -99999，因为负向的填充值在某些变量里也会出现。另一处是对质控标记的类型假设：TEMP_QC 是单字节字符数组，读出来是 b"4" 这样的字节串，不是整数 4。用整数比较会静默失败。

5.5 遍历全库的三个层级

要把整库走一遍，逻辑分三层：

第一层，列出根目录下的 DAC。第二层，对每个 DAC 列出浮标编号。第三层，对每个浮标取汇总文件或进 profiles/ 子目录。

镜像的目录页是标准的 THREDDS 目录服务，每个目录都有一份 XML 描述，其中列出下一级目录与文件。逐层拉取 XML 是最稳妥的遍历方式，比解析 HTML 页面稳定。需要注意请求量：仅第二层就要发十一次，第三层要发两万多次，第四层如果要单剖面文件则是几百万次。

实际操作中，第三层往后都不会逐层拉——用汇总文件 _prof.nc 一次取完一个浮标，能省掉两三个数量级的请求。只有确实只需要一条剖面时，才进 profiles/。

§6 层与层之间：它在本库中的位置

6.1 与逐日海温的关系

库内已有逐日海温的网格产品，那是一种把卫星与现场观测融合到规则经纬网格上的分析场，覆盖 1981 年至今，每天一张，只有表层。两者不是竞争关系，是上下游关系。

网格产品的输入里就有 Argo。它把浮标测到的表层温度当作现场真值，用来校正卫星反演的偏差。反过来，Argo 的剖面又常被拿去检验网格产品在次表层的表现——虽然网格产品本身没有次表层。

真正需要区分的是空间维度。网格产品是「处处有值」，Argo 是「路过才有值」；网格产品只到几米深，Argo 到两千米。想研究海洋热含量——那是把整根水柱的密度乘上热容再积分——只有 Argo 给得出，因为热含量的绝大部分储存在混合层以下。

6.2 与固定浮标站网的关系

库内另一条是锚系浮标与岸站的观测网。两者常被混为一谈，因为都叫「浮标」，都能测温盐。差别在根本处：

维度	锚系站网	Argo
位置	固定，坐标即测点	漂流，坐标只说明上浮点
时间序列	连续，可到分钟级	每十天一条
是否可做单点气候	可以	不可以
是否可做空间覆盖	不可以，只在少数点	可以跨洋盆
深度范围	多为表层与有限水柱	到两千米

一句话概括：锚系站网给的是点的时间深度，Argo 给的是面的立体快照。要做单站的季节内变化，用锚系；要做大尺度水柱结构，用 Argo。两者放在一起，才能既分辨时间又分辨空间。

6.3 与再分析产品的关系

再分析产品是把模式与观测同化在一起的产物，Argo 是其中的观测之一。这在评估上造成一个循环：用再分析检验 Argo，等于用 Argo 检验自己的下游产品。

判断方法是看时间。Argo 在 2000 年代中期才成规模，在此之前，再分析产品的次表层信息主要靠气候态与少量投弃式探温仪。所以 2005 年之后与之前的再分析次表层质量不可同日而语，而 Argo 本身也正是把时间切开的那个断点。

6.4 在本库中的独特位置

库内的海洋类条目，大多属于「一个东西一个文件」或「一个时刻一张图」的形状。这条条目是少数以实体为中心组织的：目录的第一层是设备，不是时间，也不是空间。

这个组织方式对使用者提出的第一个问题不是「我要哪一段时间」，而是「我要哪几颗浮标」。凡是习惯了按时间窗取数的使用者，第一次接触这份集合都会被这个转向绊一下。

§7 质量评估与局限：它不该按什么标准评价

7.0 阅读本节前的前置校正

评价这份集合时，最常见的错位是把「网格产品的标准」套上来：覆盖率、完整性、时间连续性、空间均匀性。这四项对它全都不适用，原因很简单——它不是分析产品，是观测档案。观测档案的价值不在于均匀，在于记录真实发生了什么，包括记录失败。

正确的评价框架应当围绕三件事：这条剖面在哪里、什么时候、值可不可信。前三者由身份与质量字段直接给出，后者需要在延时版本与质控标记的框架下判断。

7.1 采样偏倚：它测到的地方不等于海洋

漂流的物理决定了这份集合的空间分布。浮标随表层流走，在流场强的地方走得快、在流场弱的地方走得慢，在有环流的地方会绕圈，在副热带环流中心会被困住。结果是某些海域的观测密度极高，某些海域几乎为零。

这个偏倚不是随机的，它和水团的停留时间相关。用这份集合直接计算全球平均，等于按「浮标愿意去的地方」加权，而不是按面积加权。要纠正这一偏倚，在空间上要做面积加权或分箱，在时间上要对采样季节做均衡——这一步没有标准答案，做与不做会影响结论。

7.2 深度偏倚：两千米不是全部

浮标设计的采样深度是两千米，但实际剖面很少恰好到两千米。不同型号、不同老化阶段、不同海域的浮标，能到达的最大压力差别很大。深层海洋——尤其是四千米以下的深渊——几乎没有覆盖。

这意味着任何「全水柱」的表述都要加限定。这份集合能可靠支持的是上层与中层海洋，两千到六千米的领域要靠别的手段。

7.3 传感器的老化与漂移

盐度传感器的漂移是这份集合里最经典的质控问题。电导率传感器在海洋环境中会逐渐被生物附着、结垢、甚至机械损伤，导致读数缓慢偏离真值。这类漂移是渐进的，不是突变的，所以在单条剖面上看不出来，只有把同一个浮标长期的剖面排起来才显现。

温度传感器相对稳定，但压力传感器也会因膜片老化而产生偏移。§1.5 的案例正好展示了这一类问题的处理方式——那颗浮标的压力传感器会在浮出水面时自动归零，相当于每个循环自行做一次零点校正。这个设计让压力漂移被压到了很小的范围，因此延时质控中没有再加校正。

判断一颗浮标的盐度是否漂移，标准做法是拿它与同一海域、同一时期的其他浮标剖面比对，或与气候态比对。这项比对是延时质控的核心工作，也是延时版存在的理由。

7.4 延时不是保证

延时版本常被当作「经过质控所以可用」的通行证。这个理解大体成立，但有边界。人工质控依赖判断，判断依赖信息，信息不总充分。有些剖面在延时处理时没有足够的邻近数据做比对，审阅者只能放行。有些剖面的问题在放行之后才被识别，于是有了第二版、第三版修正。

HISTORY 字段就是为了让这些修正可被追溯。§1.5 的案例里，那条剖面有 6 条历史记录，动作分别是质控、创建、去除平台特定字段等，每条都带机构代号与软件代号。读这个字段，能看出这条剖面被改动过几次、每次由谁做、用什么工具。

7.5 许可的边界

这里要说清一件事。Argo 的定位是开放访问，前提是注明来源、引用 Argo 计划与对应浮标的 DOI。这是明确的，也是业界通行的做法。但官方没有给 SPDX 标识，剖面文件的全局属性里也没有 license 字段——只有标题、机构、来源、历史、参考、手册版本、约定七条。

这意味着任何把它写成 CC BY 的表述都是推论，不是读到的。合理的写法是：开放访问，须注明来源并引用 Argo 计划与浮标 DOI；若要在论文或产品里使用，按官方文档给出的引用格式处理。至于商用，官方文档没有给出明确的禁止或允许条款，这一点必须如实交代，而不是替官方做主。

§8 生态与版本：它为什么能持续

8.1 分工架构是它活下来的原因

这份集合的生存逻辑，不在某个机构的持续投入，而在一套分工。十一个数据中心各自负责一批浮标的采购、投放、处理与质控，汇入一个共同的目录结构。任何一个中心出问题，损失的是它那一批，不是全库。任何一个中心的技术改进，也只影响它自己那批数据的质量。

这种架构的代价是异质性。同一个字段，不同中心的处理习惯不同；同一类问题，不同中心的判断标准不同；同一份文件的格式版本，也可能不一致。使用者必须意识到，它面对的不是一份统一制作的数据集，而是十一个数据集的一次合并展示。

§1.5 的案例来自美国那个中心，它的数据里带 ACEE 项目的标注、一个具体的研究员署名、以及该中心特有的校正说明措辞。换一个中心的浮标，这些字段的内容会完全换一个样子。

8.2 版本是逐文件写的，不是整库升降的

Argo 的文件格式有版本号，写在每个文件里——FORMAT_VERSION 与 HANDBOOK_VERSION 两个字段。§1.5 的案例是格式 3.1、手册 1.2。

这意味着整库并非同时升级。老浮标的文件可能停留在旧格式，新浮标的文件用新格式。读取时必须逐文件看版本，不能假设全库一致。格式差异会体现为字段的增减、维度的命名、填充值的位置，这些差异在批量处理时不报错，只会让某一部分数据静默地读成另一种含义。

8.3 延时流是它「贵」的地方

实时流可以完全自动化：文件一到，格式检查，发布。延时流不行，它要人。一个海洋学家要逐标、逐剖面地看盐度漂移，要构造参考剖面，要判断校正是否合理，要写校正说明。这是这份集合最昂贵的部分，也是它质量的核心。

这也解释了为什么延时版会滞后数月，而且滞后时间不承诺。人手有限的中心，队列会更长。这条规律在使用时可以拿来做预期管理：小中心的延时版通常比大中心更晚。

8.4 生物地球化学扩展是另一套覆盖度

近年来有一批浮标加了额外传感器：溶解氧、硝酸盐、pH、叶绿素荧光、辐照度。这些观测在同一个目录体系下发布，但在文件与命名上有独立的一套规则。它们的空间覆盖远小于核心温盐，时间起点也晚得多。

关键区别在覆盖度。核心 Argo 的两万多个浮标，几乎都测温度与压力，大部分测盐度；带生物地球化学传感器的只是其中一小部分。把两者当成同一张网去看，会严重高估后者的可用性。做生物地球化学任务时，第一件事是先圈定有对应传感器的浮标子集，而不是在全库上做筛选。

§9 使用指引：三条路径，一份最小实现

9.1 三条路径

路径	适用	做法	代价
单标深挖	研究某颗浮标的完整履历	取 meta、prof、Rtraj、tech 四个文件	几次请求，几十 MB
按海域取样	研究某片海的季节循环	先遍历浮标元数据的投放位置，圈定范围，再逐标取汇总	千次量级请求
全库批处理	建气候态、做质控学习	逐标取汇总文件，本地汇总	两万余次请求，TB 级存储

第二条路径的关键在第一步。浮标编号本身不含位置信息，要先打开浮标的元数据文件，读 LAUNCH_LATITUDE 与 LAUNCH_LONGITUDE，才能知道它在哪下水。可用的海域筛选应当放在投放位置上，而不是放在剖面位置上——后者要读完全部数据才知道。

9.2 一份最小实现

下面这段把 §1.5 的案例的 140 条剖面整理成一张表，并按浮标分组做一次最简单的时间差分：

import numpy as np, math
from scipy.io import netcdf_file

def great_circle(lat1, lon1, lat2, lon2):
    R, p = 6371.0, math.pi / 180
    a = (math.sin((lat2 - lat1) * p / 2) ** 2
         + math.cos(lat1 * p) * math.cos(lat2 * p)
         * math.sin((lon2 - lon1) * p / 2) ** 2)
    return 2 * R * math.asin(math.sqrt(a))

with netcdf_file("13857_prof.nc", "r", mmap=False) as f:
    v = f.variables
    cyc = v["CYCLE_NUMBER"][:].astype("int32")
    t = v["JULD"][:].astype("float64")
    la = v["LATITUDE"][:].astype("float64")
    lo = v["LONGITUDE"][:].astype("float64")

order = np.argsort(t)
cyc, t, la, lo = cyc[order], t[order], la[order], lo[order]
dt = np.diff(t)
dist = [great_circle(la[i], lo[i], la[i + 1], lo[i + 1])
        for i in range(len(t) - 1)]
print("剖面数", len(t), "时间跨度天数", round(t[-1] - t[0], 1))
print("相邻剖面间隔天数 最小", round(dt.min(), 2), "最大", round(dt.max(), 2))
print("相邻剖面间隔 中位", round(float(np.median(dt)), 2))
print("相邻位置间距 均值公里", round(float(np.mean(dist)), 1))

在 §1.5 的案例上，输出的核心数字是：剖面数 140，时间跨度 1528.97 天，相邻间隔最小 10.67 天、最大 11.33 天、中位接近 11 天，相邻位置间距均值约 52.2 公里，累计约 7252 公里。

这几个数说明了一件事：「每十天一个剖面」是个设计参数，不是数据的性质。真实的间隔在十天上下浮动，浮动的来源是浮标在水面停留传数据的时间不同、下沉前的等待时间不同、以及各次循环的实际深度不同。做时间序列分析时，若按严格十天重采样，误差会累积。

9.3 切分与泄漏

做机器学习时，切分必须在浮标层面做。同一颗浮标的 140 条剖面构成一段连续的时空轨迹，相邻两条的物理状态高度相似。若按剖面随机切分，训练集与测试集会共享同一段水体，测试分数会被系统性高估。

正确做法是：按浮标编号分组，整组进训练或整组进测试。若要做时间外推评估，还要在浮标组的基础上再加时间切分——用较早的剖面训练，较晚的剖面测试。

9.4 一个常见的数据管道

从原始文件到可训练的张量，通常要过这几步：

第一步，按浮标取汇总文件。第二步，读 STATION_PARAMETERS 确认有盐度。第三步，筛掉 DATA_MODE 为 R 的剖面（若要延时版）。第四步，按 *_QC 与填充值掩码无效层。第五步，按压力重采样到统一网格——这是必须做的，因为原始层不等距、层数不一致。第六步，按浮标分组切分。

第五步是最容易被草率处理的一步。重采样到 5 分巴、10 分巴还是 1 米，会直接改变模型的感受野。深海压力变化小、温度梯度小，浅层压力变化大、温度梯度大，统一网格在浅层欠采样、在深层过采样。分层重采样能缓解，但那是另一个设计决策。

§10 AI 使用声明与总结

10.0 先说清「一份剖面」这个词

沿用了整个海洋学界的习惯说法，但它比字面上窄。一份剖面通常只对应一次上浮过程，只给一条上升曲线。下降过程虽然也有采样，但多数型号只在上升段完整记录，下降段要么不采、要么只采少量层，另外以 DIRECTION 字段区分。§1.5 的案例全部 140 条的方向字段都是上升，没有任何一条下降剖面。

这个区分不是学究式的。若是想构造一条水柱的完整观测序列，只靠上升段已经足够；若是想研究同一条剖面的上下行差异——比如传感器的时间常数造成的滞后——就得确认浮标有没有下降段，而这在多数标上是没有的。

顺着这一点再看一个容易忽略的细节：上升过程需要几个小时，而文件里只有一个时刻。某个两千米的剖面，如果把上升起止时间算出来，每层的时刻各不相同，层与层之间相差几十秒到几分钟。对绝大多数应用，这个差异无所谓；但对声速、气体交换、短周期内波这类问题，它就是一个不能忽略的系统性误差，而且没有任何字段直接给出，必须自己从轨迹文件的起止时刻推算。

10.1 适用任务

任务	适配度	注意
次表层温度预测	高	必须按浮标切分，按压力重采样
海洋热含量估计	中高	空间采样偏倚需校正
盐度漂移校正的学习	高	原始值与校正值配对是天然标签
剖面缺层填补	高	缺测分布本身是研究信号
水团识别与聚类	中	需先解决层与深度不对齐
生物地球化学预测	低到中	覆盖度远小于核心变量，须先圈定子集
固定点时间序列研究	不适用	浮标不停留

10.2 使用声明要点

使用时应当交代几件事：取用的是实时版还是延时版、取数的时间点、是否包含质控标记为 4 的数值、盐度覆盖率、以及在哪个深度范围内使用。这几项直接决定结论的可复现性。

还应当交代切分方式。按浮标切分与按剖面切分，得到的评估结果差得很多，不写清切的什么，就无法判断结论可信度。

伦理层面有一件事需要说明：这份集合不含任何个人数据。浮标是设备，标定与维护人员的名字以首席研究员的形式出现在元数据里，那是公开的机构信息，不是个人观测数据。下游若涉及渔业、保险、航运的风险评估，需披露空间代表性误差，因为浮标的采样偏倚会直接影响区域的结论。

10.3 总结

这份集合的分量不在体积，在形状。它把一整片海洋的观测，按「哪颗浮标」重新组织了一遍。这个组织方式在数据库里少见，在实地观测里却是自然——因为观测的物理单位本来就是一个会移动、会工作、会失联的设备，而不是一个坐标。

理解了这一点，后面的所有取舍就顺了：为什么位置只有一个上浮点，为什么实时与延时并存，为什么原始值不覆盖，为什么一标一档，为什么缺测用 99999 而不是 NaN，为什么盐度覆盖不全。这些都是「设备在漂流」这个前提的直接后果，不是设计缺陷。

§11 常见误读与避坑清单

常见说法	实际情况	证据
「两万余个浮标目录，就是两万多条剖面」	目录只是浮标数，剖面要到每个标目录里数	逐 DAC 计数，合计约两万两千
「一条剖面的位置就是那对经纬度」	那只是上浮点，下潜点没有字段记录	§1.5 的案例相邻剖面平均相距 52.2 公里
「间隔固定为十天」	设计参数是十天，实际在 10.67–11.33 天之间浮动	案例 140 条剖面的时间差分
「DATA_MODE 是 D 就是延迟模式」	D 表示混合，同一文件里可能有实时值	格式手册对三值的定义
「延时版一定比实时版准」	延时是人工判断，也可能放过或误判	HISTORY 与校正说明字段的结构
「原始值会被校正值覆盖」	两组变量并存，谁也不覆盖谁	文件里成对的 * 与 *_ADJUSTED
「缺测是 NaN」	填充值是 99999，读成浮点数不会自报	案例 15,820 个温度槽位里 1665 个为 99999
「每颗浮标都测盐度」	只测温压的浮标另列灰色名单	案例的传感器清单只有温度与压力两项
「只看 ADJUSTED 变量最安全」	未校正时该变量整列为填充值	案例第 140 条剖面 TEMP_ADJUSTED 全是 99999
「质控标记为 4 的值会被置为空」	它只是一个正常浮点数，需自己掩码	TEMP_QC 全为 4 而 TEMP 有值
「文件里写了许可是 CC BY」	全局属性只有七条，没有 license 字段	OPeNDAP 的 .das 返回
「所有浮标目录里都有 R 版」	历史剖面的实时版被取代后不再保留	案例 140 个文件全部以 D 开头，请求 R 版得 404
「目录按时间分」	第一层是数据中心，第二层是浮标	镜像目录的三层结构
「切分按剖面随机即可」	同标相邻剖面高度相关，会造成泄漏	案例单标 140 条连续剖面
「格式版本全库统一」	版本逐文件写入，老文件停旧格式	FORMAT_VERSION 在每个文件里

DAIMS 适用性评估

维度	评分	说明
数据来源可追溯	强	每标有元数据、每改一次有历史记录、每次校正有说明与执行日期
身份唯一性	强	浮标编号与循环序号构成唯一键，编号规则含数据中心与流水号
时间一致性	中	时刻有统一定义与纪元，但剖面内各层无独立时刻
空间定位	弱到中	只有上浮点；下潜点、剖面内位置均需推算
缺失值处理	中	填充值统一但不用 NaN，需显式掩码
观测值可信度	中到强	逐层与逐条两级质控标记，延时版由人工完成
许可清晰度	中	开放访问的意图明确，但无 SPDX、无文件内 license
版本管理	中	逐文件写版本，整库不统一升降
可直接训练性	弱	需重采样、掩码、分组切分三道加工才可用
样本独立性	弱	同标剖面高度相关，必须按标分组

附录 A 速查卡

键	值
全名	Argo Global Data Assembly Center 浮标剖面集合
镜像入口	data.nodc.noaa.gov/thredds/catalog/argo/gdac/catalog.html
平行目录	…/catalog/argo/gadr/catalog.html
取数前缀	…/thredds/fileServer/argo/gdac/<dac>/<编号>/
OPeNDAP 前缀	…/thredds/dodsC/argo/gdac/<dac>/<编号>/
主键	PLATFORM_NUMBER + CYCLE_NUMBER
时刻单位	days since 1950-01-01 00:00:00 UTC
缺测值	99999
两套值	裸名与 _ADJUSTED 后缀成对
三种模式	R 实时 / A 延时 / D 混合
文件类型	meta、prof、Rtraj、tech、profiles/
许可	开放访问，须注明来源并引用，无 SPDX

附录 B 变量与属性表

字段	类型	说明
PLATFORM_NUMBER	字符	八字符浮标编号，WMO 标识规则 A9IIIII
CYCLE_NUMBER	整型	浮标内循环序号
JULD	双精度	剖面时刻，自 1950-01-01 起的日数
JULD_LOCATION	双精度	定位时刻，通常略晚于 JULD
LATITUDE / LONGITUDE	双精度	上浮点坐标，东经北纬为正
PRES / PRES_ADJUSTED	单精度	压力，分巴
TEMP / TEMP_ADJUSTED	单精度	温度，摄氏度
PSAL / PSAL_ADJUSTED	单精度	实用盐度，无量纲
*_ADJUSTED_ERROR	单精度	校正不确定度；未校正时为 99999
*_QC / *_ADJUSTED_QC	字符	逐层质控标记 1–9
PROFILE_TEMP_QC	字符	整条剖面概括标记
DATA_MODE	字符	R / A / D
STATION_PARAMETERS	字符	该标可提供的参数清单
HISTORY_*	混合	修订动作、机构、时间、软件、质控测试串
SCIENTIFIC_CALIB_*	字符	校正方程、系数、说明、日期

附录 C 术语表

术语	含义
DAC	数据汇编中心，负责一批浮标的处理与质控
GDAC	全球数据汇编中心，各 DAC 的共同出口
循环	浮标下潜到上浮的一趟，对应一条剖面
剖面	一次下潜上浮过程中沿深度的观测序列
实时模式	自动处理、未经人工校正的版本
延时模式	经人工校正并写入质控标记的版本
灰色名单	只测温度压力、无盐度数据的浮标名录
插值起点	由上下两个上浮点推算出的下潜位置
分巴	压力单位，数值上近似等于米
填充值	表示缺测的哨兵值，此集合为 99999

附录 D 常见问题

Q1：这份集合能直接当输入训练深度模型吗？
不能直接用。要先按压力重采样统一深度网格，掩掉填充值与低质控标记，再按浮标分组切分。三道加工缺一不可。

Q2：实时版与延时版的差别到底有多大？
没有统一答案。差别集中在盐度——温度与压力的变化通常很小，盐度的系统性漂移才是延时质控的主要战场。想量化，办法是取同一浮标同一循环的两版数值逐层相减。

Q3：为什么同一颗浮标的剖面层数会不一样？
采样深度范围不同、传感器状态不同、传输出错都会改变层数。原始层不等距，跨剖面比较前必须重采样。

Q4：能不能只用最新的延时版，丢掉实时版？
可以，前提是接受近一两年数据的缺失。延时版滞后数月至一年多，最新的剖面通常只有实时版。

Q5：轨迹文件比剖面文件更有用吗？
取决于问题。要研究漂移路径、环流输送，轨迹文件是唯一来源；要研究水柱结构，剖面文件才是本体的。

Q6：能不能用浮标编号推断它的投放国家和海域？
编号的前半段能推断负责的数据中心，但不能推断海域——浮标可以被任何国家在任何海域投放，编号只记录归属，不记录位置。

Q7：官方入口打不开怎么办？
本次核验中，多个主要入口在特定网络环境下不可达，而美国国家环境信息中心的镜像全程可用。遇到入口不通时，优先试这个镜像，而不是推测数据已下线。

Q8：生物地球化学浮标的数据在同一个目录吗？
在同一套目录体系下，但文件命名与要素集合独立，且覆盖度远小于核心温盐。用之前先确认目标浮标确实装了对应传感器。

编辑说明

核验时间 2026-10-29。方法：逐层列举 NCEI 镜像的 THREDDS 目录，从根目录的 11 个 DAC 下钻到每个 DAC 的浮标清点，合计 22,080 个浮标目录；对浮标目录、剖面目录与单个文件做可达性验证，确认 HTTP 200 与 OPeNDAP 服务均可用；下载 13857 号浮标的 meta、prof、Rtraj、tech 四类文件与第 140 条剖面的单剖面文件，用 scipy 读取变量、维度、全局属性与质控字段，取得变量数、层数、时刻、坐标、填充值位置、质控标记分布、校正说明原文与历史记录；对平行目录 gadr 做结构核验，确认其按海盆与年月日组织、单文件为单剖面；对 Argo 项目主页、法国原始镜像、SEANOE 与两个欧洲运营平台做可达性测试，全部超时，故正文只按可用的镜像陈述，并对不可达入口如实标注。剖面总量未做逐标清点，正文只给量级表述而不给精确数；DAC 的浮标计数首轮因单次请求上限出现截断，已重置超时参数重取完整目录后计数。全部数字中，「52.2 公里」「7252 公里」「1528.97 天」「1665 个填充值」四项为由单标文件计算所得，其余为目录级别计数。未做任何分布统计，因此全文没有温盐均值、频次分布或区域偏差数字。单剖面文件的 R 版本在原路径返回 404，属历史剖面不保留实时版的正常现象，正文据实描述而未作异常处理。

---

相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：

• era5-single-levels — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康 / 疾病监测
• oisst-v2-1 — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康 / 疾病监测
• ibtracs — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康 / 疾病监测
• our-world-in-data — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康
• ndbc-buoy — 共享标签：公共卫生与流行病学 / 时序数据 / 疾病监测
• noaa-cors-gnss — 共享标签：公共卫生与流行病学 / 时序数据 / 疾病监测
• amrnet — 共享标签：公共卫生与流行病学 / 全球健康 / 疾病监测
• ghcn-daily — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康
• cmip6-esgf — 共享标签：公共卫生与流行病学 / 时序数据 / 全球健康
• jhu-csse-covid-19 — 共享标签：公共卫生与流行病学 / 时序数据 / 疾病监测

导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。