信息速览
INFOBOX
| 项 | 值 |
|---|---|
| 全名 | GISAID EpiFlu™ Database（流感病毒基因序列库） |
| 所属平台 | GISAID Initiative，下设 EpiFlu、EpiCoV、EpiPox、EpiRSV、EpiArbo 五个库 |
| 运营主体 | Freunde von GISAID e.V.（Friends of GISAID），注册于德国的非营利协会 |
| 托管方 | 德意志联邦共和国，2010 年起担任平台与 EpiFlu 的官方托管方 |
| 上线时间 | 2008 年 5 月，第六十一届世界卫生大会期间于日内瓦发布 |
| 规模（2019 官方口径） | 约 30 万毒株 / 约 120 万条片段序列 |
| 平台总量（2026-10 官网） | 22,390,000 余条序列提交（五个库合计，非 EpiFlu 单库） |
| 组织单位 | 毒株（EPI_ISL）为一极，基因片段（EPI）为另一极，每毒株至多 8 段 |
| 覆盖范围 | 甲型流感全部 H/N 亚型；乙型 Victoria 与 Yamagata 谱系；人、禽、猪、马、犬、环境等宿主 |
| 访问方式 | 注册 + 签署数据库访问协议（DAA），通过网页检索下载；免费 |
| 许可 | 非独占、可撤销的访问许可；不明示开放许可，禁止再分发 |
| 不含 | 原始测序读段、完整临床表、全库打包文件、质量分级 |
| 最大的坑 | 它是需签协议的受控资源，不是可再分发的公开数据集 |
EpiFlu 是 GISAID 平台下专门收录流感病毒基因序列的数据库，与收录新冠病毒的 EpiCoV、收录猴痘病毒的 EpiPox 并列，是同一套共享机制下按病原点分开的若干个库之一。它收录的是已经拼好的各个基因片段，不是原始测序读段；它以毒株为单位组织记录，每个毒株下面挂八个片段。这个库的规模在流感领域没有对手，但它的取数方式与 GenBank 一类公共域档案根本不同。
它最不可替代的地方不在体量，而在准入规则。2006 年前后，H5N1 序列的共享陷入僵局：一些国家不愿把序列放进匿名可取的公共库，担心被抢先发表，也担心失去对衍生生物材料的议价能力。EpiFlu 的设计是把「谁在用、用了什么」变成可核查的事实——所有使用者实名注册、签署协议、发表时逐一背书原始实验室与提交实验室。代价是数据不能自由再分发，收益是很多原本不会公开的序列进了库。这种设计使它在流感监测上有特殊位置：世界卫生组织每半年更新一次疫苗株建议，其依据的序列数据大量经由这里流转。但它同时意味着，凡是要把流感序列当成可自由打包的训练语料的项目，都会在这一步卡住。一屏速览见下表。
§1 速览：它到底是什么
§1.1 一句话定位
EpiFlu 是一个需要实名准入的流感病毒基因序列库：序列免费读，但读之前要注册、要签协议、要承诺不转手；读完之后发表，要把每一株病毒背后的两个实验室都写进致谢。
这句话里每一个分句都是一道真实的约束，不是修辞。把它与「公开数据集」混为一谈，是使用这个库最常见的失败起点。
§1.2 平台结构：五个库，一套机制
GISAID 不是一个数据库，而是一个平台，按病原点切分成若干库。理解这一层结构，才能回答「EpiFlu 的数据会不会混进新冠序列」这类问题。
| 库 | 病原点 | 定位 |
|---|---|---|
| EpiFlu | 流感病毒（甲、乙型为主） | 平台的起点，2008 年随平台上线 |
| EpiCoV | SARS-CoV-2 | 2020 年起承接新冠序列，规模一度为全平台之首 |
| EpiPox | 猴痘病毒 | 承接 2022 年以来的猴痘疫情序列 |
| EpiRSV | 呼吸道合胞病毒 | 按 RSV A/B 亚群组织 |
| EpiArbo | 虫媒病毒（登革、寨卡、基孔肯雅等） | 平台最新的一个库 |
五个库共用同一个账号体系、同一份数据库访问协议、同一套策展流程，但各自独立成库、独立编目、不互相混装。EpiFlu 的登录号与 EpiCoV 的登录号是两套体系，不能互换。
这一结构有一个容易忽视的后果：GISAID 官网首页那个总量数字是五个库的合计，不能当作 EpiFlu 的规模（详见 §7.1）。EpiFlu 当前没有公开的单库实时计数，官方最后一次给出 EpiFlu 专属口径是 2019 年的数据库海报：约 120 万条片段序列，来自近 30 万毒株。
§1.3 三十秒决策卡
| 你的处境 | EpiFlu 能帮你什么 |
|---|---|
| 要复现某篇论文的流感系统发育树 | 论文里的 EPI_ISL 号能直接定位毒株，谱系字段由平台统一注释 |
| 要做疫苗株与流行株的抗原距离分析 | 世界卫生组织各合作中心提交的候选疫苗株都在库里 |
| 要追踪某亚型在禽类中的跨洲传播 | 禽源记录的宿主字段可细分到物种，地理字段到省市 |
| 要评估抗病毒药物耐药位点的全球流行 | 神经氨酸酶片段与耐药注释可一并取，但需自行统计 |
| 要建一个可自由再分发的流感序列语料 | 不行，协议禁止再分发（详见 §5） |
| 要拿到原始测序读段做从头组装 | 不行，库里只有已拼好的片段 |
左列写的是使用者的处境，不是数据库的功能清单。这个区别决定了读完之后能不能立刻做决定。
§1.4 不适合谁
如果你的需求是「找一批能打包上传到 HuggingFace 的流感序列做预训练」，EpiFlu 给不了。它能给你的是一份可以分析、可以引用、但不能转手的数据，交出去的只能是统计结果、模型参数与致谢清单，不是序列本身。
如果你的需求是「拿到测序原始数据做质量评估或从头拼接」，EpiFlu 也给不了。它收到的已经是组装并注释过的片段，读段质量、覆盖深度、污染比例这些信息在库里看不到。
如果你的需求是「一次性下载全库做批量比对」，技术上可以做，但协议要求一次有明确研究目的的检索，全库爬取会触发平台的反爬机制并导致账号被暂停（详见 §5.4）。
§1.5 一句话记住边界
EpiFlu 是把流感序列借给你看、借给你算的地方，不是把序列送给你的地方。
§2 数据构成与覆盖范围
§2.1 记录的层级：毒株与片段
EpiFlu 最小的编目单位不是「一条序列」，而是「一个毒株」。这是它与 GenBank 最容易被忽略的结构差异。
一个毒株（isolate）对应一次分离事件，含病毒名、宿主、采集地点与时间、传代历史。每个毒株下面挂至多八个基因片段，分别对应流感病毒的八条 RNA：PB2、PB1、PA、HA、NP、NA、MP、NS。每个片段有独立的登录号。
毒株层 EPI_ISL_xxxxxxx 一次分离，一个宿主，一个时间地点
├─ PB2 片段 EPIxxxxxx
├─ PB1 片段 EPIxxxxxx
├─ PA 片段 EPIxxxxxx
├─ HA 片段 EPIxxxxxx ← 亚型命名依据，也是绝大多数分析用的那一段
├─ NP 片段 EPIxxxxxx
├─ NA 片段 EPIxxxxxx
├─ MP 片段 EPIxxxxxx
└─ NS 片段 EPIxxxxxx
这个结构决定了三件事。
第一，片段数不整齐。 有的毒株提交全部八段，有的只提交 HA，有的只提交 HA 与 NA。做全基因组分析时，按「八段齐全」筛一遍，样本量会显著缩小；做单片段分析时，用 HA 段能得到最大样本量。
第二，同一毒株可以有多条记录。 同一分离株经不同传代历史后测序，会被记成不同的毒株记录。库不做跨记录去重，论文里见到的重复计数大多来源于此。
第三，片段的登录号不能当毒株号用。 引用序列时应给 EPI_ISL，给片段号会让使用者无法定位到宿主与时间。
§2.2 分型与谱系
EpiFlu 的检索界面上，分型是一个独立的筛选项，与宿主、地点、时间并列。
| 层级 | 取值 | 说明 |
|---|---|---|
| 型 | 甲型（A）、乙型（B） | 检索框里给的是 A/B/C 这类字母，实际存量以甲、乙两型为主 |
| 甲型 H 亚型 | H1 至 H16 | 编号由血凝素蛋白的抗原性分组决定 |
| 甲型 N 亚型 | N1 至 N9（H16 常配 N3 等） | 编号由神经氨酸酶分组决定 |
| 甲型常见组合 | H1N1、H1N1pdm09、H3N2、H5N1、H5N8、H7N9、H9N2 | 前两个是人季节性流感与 2009 大流行株，后四个是禽流感跨种事件的主角 |
| 乙型谱系 | Victoria、Yamagata | 乙型不分 H/N，只分谱系；2020 年后 Yamagata 系检出大幅减少 |
这张表里有两处需要留意。H1N1pdm09 是一个独立取值，不与季节性 H1N1 合并，因为两者抗原性与流行病学完全不同。乙型的 Yamagata 系在 2020 年后全球检出骤减，是这个库里近几年最明显的一处「某类记录不再增长」。
§2.3 宿主与地理覆盖
流感病毒是人类、禽类、猪、马共有的病原，EpiFlu 把这份跨物种的负担照单收录。
| 维度 | 覆盖情况 |
|---|---|
| 宿主大类 | 人、禽、猪、马、犬、猫、海洋哺乳动物、环境样本 |
| 禽类细分 | 可细分到物种或类群，如鸡、鸭、野鸟、鸻鹬类、水禽 |
| 地理粒度 | 国家是最稳的一级，往下到省/州、市，粒度随提交实验室的填写习惯而变 |
| 时间粒度 | 采集日期，精度从精确到日、到月、到年不等 |
| 数据来源国 | 官网列举的伙伴机构覆盖阿根廷、巴西、中国、刚果共和国、埃塞俄比亚、印度尼西亚、马来西亚、俄罗斯、塞内加尔、新加坡、南非 |
地理粒度的不均匀是这个库的结构性特征，不是缺陷：一个国家级流感中心可能填到市，而一次禽流感应急提交可能只填到国家。做跨国比较时，国家一级最稳，市一级只能在同一提交方内部做纵向比较。
§2.4 四块元数据
EpiFlu 的元数据按对象分块，四块各回答一个问题。
| 块 | 回答什么 | 主要字段 |
|---|---|---|
| 分离株与病毒 | 这是什么病毒 | 病毒名、型、H/N 亚型或乙型谱系、传代历史、片段完整性、抗原性特征与抗病毒敏感性（部分记录） |
| 地点与时间 | 从哪儿、什么时候 | 国家、省/州、市、采集日期、提交日期、标本来源国 |
| 宿主与患者 | 从谁身上来 | 宿主大类与亚类、禽类科属种、家养状态；人源的患者年龄、性别、健康状况、疫苗接种史、抗病毒治疗 |
| 实验室与责任 | 谁采的、谁测的 | 原始实验室（采样的那个）、提交实验室（测序并上传的那个）、实验室所在国家与地址 |
第三块内部有一条人为的分野。人源记录问的是患者：年龄、性别、健康状况、接种史、是否用过抗病毒药。动物源记录问的是宿主群体：物种到科、家养还是野生、健康状态、是否接种过疫苗、用的是哪种疫苗株。两套问题不可互换——把动物的「接种状态」当作人的「疫苗接种史」统计，会得到没有意义的结论。
第四块是这个库与其他序列库最大的差别。它存在的意义不是行政留痕，而是让致谢成为可能：一篇用 EpiFlu 数据发表的论文，参考文献之外还要列出所有贡献毒株的两个实验室。
§2.5 一条记录的形态
一条 EpiFlu 记录在检索结果里的样子，大致是这样（以库里 2026 年 10 月新增的一例人感染 H5N1 为原型，字段名按平台界面还原）：
EPI_ISL_205571770
Virus name : A/Washington/xxx/2026 (H5N1)
Type : A
Subtype : H5N1
Host : Human
Collection : 2026-10-12 Washington, United States
Segments : PB2 PB1 PA HA NP NA MP NS (8/8 complete)
Originating : [某州公共卫生实验室]
Submitting : [美国 CDC]
Released : 2026-10-23
读到这条记录，能立刻拿到的是：亚型、宿主、时间、地点、完整性、两个实验室、放行日期。拿不到的是：这个病例的临床表现、病毒载量、测序平台型号、覆盖深度。后者从未进入 EpiFlu 的字段设计。
这一条记录值得单独拆开看，因为它把本文后面的几条主张全部串起来了。
采集到放行是十一天。 10 月 12 日采集，10 月 23 日放行。这意味着从病毒被检出到全球研究者可用，中间隔的不是几个月。「策展后立即开放、不许压到论文被接收」这条规则，在这条记录上是兑现了的（§3.1）。同期平台发布了这条序列的短新闻稿，说明的是同一件事：这个库的日常运转以「周」为单位，而不是以「刊期」为单位。
两个实验室都写着。 原始实验室是采样的州公共卫生实验室，提交实验室是测序并上传的美国 CDC。这两个名字不是附注，是发表时必须出现在致谢里的两个实体（§3.4）。一个用了一万条序列的项目，致谢表就得列出一万条记录背后涉及的全部实验室——这就是为什么 EPI_SET 号不是可选项，而是把致谢工作变得可管理的前提。
八个片段齐全。 这不是常态，是较优的情况。前文说过，全库平均每个毒株只提交约四个片段（§4.5）。这条例子的八段齐全，让它能直接进全基因组重配分析；而同一时期大多数只提了 HA 段的记录，进不了。
它带着一条亚型之外的谱系注释。 平台稿把它归入 H5N1 的某一重配分支，并指出它在 NA 段携带一个已知会轻微降低神经氨酸酶抑制剂敏感性的替换。这条信息来自注释，不是来自序列本身——说明这个库的价值有一半在序列上，另一半在有人替你把序列放进了分类框架里（§9.3）。
最后是它的边界。 这条记录里没有任何临床信息：病人年龄、转归、是否用过抗病毒药，全都不在。想把这些问清楚，得回到病例报告与监测系统，而不是数据库。这正是 §2.8 那张表要说明的事。
§2.6 与同类资源的定位差异
| 资源 | 核心内容 | 与本库的差异 |
|---|---|---|
| EpiFlu | 已组装片段 + 实验室溯源的流感序列 | 覆盖最全，流感专属，需协议准入 |
| GenBank 流感部分 | INSDC 归档的流感序列 | 匿名可取、可再分发，但部分序列不进来 |
| BV-BRC | 病原基因组与专项注释 | 做过统一重注释，病毒占九成，含流感但不以其为主 |
| Nextstrain 公开树 | 基于整合数据集的系统发育树与元数据 | 只有整合后的抽样，非原始库 |
| GISAID 官方系统发育页 | 平台自建的流感谱系树 | 只能在线看，不能导出建树所用序列 |
判断规则很简单：要最全的流感序列 → EpiFlu；要可再分发的流感序列 → GenBank；要现成的树看谱系走向 → GISAID 系统发育页或 Nextstrain。
§2.7 病毒名：库里唯一人可读的标识
EpiFlu 的记录里有一套登录号，也有一套病毒名。登录号用于机器定位，病毒名用于人眼识别。这套命名有固定的分段结构，读懂它比想象中有用。
A/Washington/xxx/2026 (H5N1)
│ │ │ │ └ 亚型括注（乙型则标谱系）
│ │ │ └ 分离年份
│ │ └ 分离序号，同一地点同一年内编号
│ └ 分离地点
└ 型别字母
六个位置各承载一类信息，每一类都对应检索界面的一个筛选维度。这个对应关系不是巧合：病毒名是从这些字段自动拼装出来的，因此按名筛选与按字段筛选会得到同一个集合。
这几个位置里，只有「分离地点」与「分离序号」没有受控词表。型别字母与亚型括注由平台按提交的字段生成，是标准化的；地点与序号则由提交实验室自己写。于是同一个城市会出现不同拼法，同一个年份内的序号会跳号、会补零也会不补零。
使用者容易忽略的是命名并非全库统一。不同实验室、不同年代提交的记录，在地点写法（城市名与国家名混用）、序号格式（补零与否）、亚型标注（是否括注谱系）上存在差异。把它当字符串直接用，会在合并数据集时产生假重复；正确做法是拆成字段再用，或者干脆只用平台提供的结构化字段。
这套命名还有一个实用价值：它是唯一能跨库对照的标识。同一个毒株若同时出现在 EpiFlu 与 GenBank，两者的登录号不同，但病毒名往往一致。做跨库去重时，病毒名加采集日期是最稳的组合键，登录号反而不行。
§2.8 一条记录里没有的东西
列出「有哪些字段」是容易的，列出「没有哪些字段」更能界定边界。
| 常被期待、实际没有 | 说明 |
|---|---|
| 原始测序读段 | 只有组装后的片段，读段在测序实验室或 INSDC 的读段档案里 |
| 测序平台与仪器型号 | 不在元数据字段设计中，个别提交者会写进备注 |
| 覆盖深度与读段数 | 同上，非结构化字段 |
| 完整的临床表 | 只有年龄、性别、接种史等少数可选字段 |
| 序列质量评分 | 平台不做质量分级 |
| 构建好的系统发育树 | 平台有在线树，但不能导出建树所用的序列集 |
| 抗体滴度等实验测定值 | 部分记录有抗原性特征与抗病毒敏感性标注，但不系统 |
这张表的下半部分比上半部分更重要。做流感模型的人常假设「数据库里应该有测序质量信息」，实际没有；也常假设「平台上的树可以下载来复现」，实际只能看。这两处假设落空，是项目返工的高频起点。
§3 准入层：注册、协议与致谢
§3.1 为什么它要设一道门
把 2006 年的僵局讲清楚，这道门的合理性才立得住。
当时的矛盾不在技术，在激励。一份 H5N1 序列放进匿名可取的老库，任何人都能立刻下载、分析、发表，而提供样本与测序的实验室可能在论文出来之前就被抢先——这就是所谓 scoop。另一层顾虑来自国家：病毒样本是实物资源，衍生的疫苗与诊断试剂有商业价值，一些国家把序列的公开视为放弃了议价筹码。
EpiFlu 的解法是分离两件事：数据可读，但取用者实名且受约束。数据一旦提交，必须在策展后立即向全体注册用户开放，不能压到论文被接收——这一条堵住了「留着自己发」的路。同时，协议承诺提交者保有其数据的权利，使用者必须背书致谢——这一条堵住了「白拿」的路。
结果是：很多原本永远不会进公共库的序列，进了库。这是 EpiFlu 在流感领域不可替代的真正原因。
§3.2 注册的三道门槛
| 门槛 | 具体要求 | 实际影响 |
|---|---|---|
| 实名 | 填写真实姓名、机构、职务、地址、邮箱 | 信息不全或拼写错误会拉长审核 |
| 机构邮箱 | 官网明确建议使用机构邮箱 | 用 Gmail、Yahoo、QQ、126、163 等公共邮箱「很可能降低优先级或造成显著延迟」 |
| 签署协议 | 逐条勾选并接受数据库访问协议 | 接受即生效，无谈判空间 |
注册本身免费。审核由人工完成，通过后拿到个人凭证，一个账号可跨五个库使用。
§3.3 协议里最要紧的四条
数据库访问协议（Database Access Agreement）是一份法律文本，但对使用者而言，实质约束只有四条。
| 条款位置 | 内容 | 对使用的实际含义 |
|---|---|---|
| 第 2(b) 条 | 不得把数据与任何其他流感序列数据库联用、不得借其他门户或机构网络让他人访问 | 不能把 EpiFlu 数据并入自建的镜像库 |
| 第 2(d) 条 | 除协议授权的用户外，不得向任何第三方分发数据 | 不能把 FASTA 发给未注册的同事 |
| 第 2© 条 | 发表时须以原始来源致谢原始实验室与提交实验室 | 致谢不是客气，是义务 |
| 第 2(e) 条 | 应尽力与原始实验室合作并让其参与分析 | 论文署名与致谢之外，还要求建立联系 |
此外协议第 1 条给的是非独占、全球、免版税、不可转让、可撤销的许可。这个措辞组合意味着：你可以用，但不能把「用」这个权利再授权给别人，而且平台可以撤回。
§3.4 致谢的三种写法
GISAID 官方给了一套固定的致谢写法，用 EpiFlu 数据发表的论文应照此执行。
| 位置 | 应写什么 |
|---|---|
| 正文首次提及 | 以脚注形式引用指定文献，流感相关场景用 Shu 与 McCauley 2017 年发表在 Eurosurveillance 的那篇 |
| 致谢段首句 | 用官方给定句式，感谢原始实验室（取样）与提交实验室（测序与上传） |
| 数据可用性 | 给出 EPI_SET 号或其对应 DOI，使他人能在平台上原样复现检索集 |
第三条最容易被漏掉，也最实用。EPI_SET 是一次检索的固化物，有了它，别人不需要知道你的筛选条件也能拿到同一批毒株。没有它，一篇论文的「数据可用性」声明就是不完整的。
§3.5 发布禁运：一个少见的附加条款
EpiFlu 允许提交者对数据设置临时发布禁运。禁运期内，第三方不得公开发表使用该数据的成果，除非获得提交者书面同意。禁运不阻止数据分析，只阻止公开发表。
这条规则的设计意图是保护提交者的首发权，但它给使用者带来一个必须提前确认的事项：在一个以禁运数据为核心的课题开题前，先确认涉及的毒株是否处于禁运期。 这个信息在平台界面上可见，但不会有人主动提醒。
§4 质量层：提交、策展与已知问题
§4.1 提交是怎么发生的
EpiFlu 的数据来自三方：各实验室直接提交、从公共域档案导入、以及平台间的补充交换。前两者是主体。
| 提交方式 | 适用场景 | 特点 |
|---|---|---|
| 单条上传 | 少量毒株 | 走网页表单，字段逐项填写 |
| 批量上传 | 一个流行季的全部毒株 | 用带宏的表格模板，一次可提交数百条 |
| 命令行工具 | 常规化提交的实验室 | 平台提供的命令行提交工具，适合自动化 |
| 公共域导入 | 只在 GenBank 发表的序列 | 平台定期从公共库导入，以保证「完整画面」 |
第三种的存在意味着：一个国家级实验室的常规监测数据可以做到流水线式入库，而一次应急事件的序列往往走单条上传。这解释了为什么同一个库里，不同来源的记录在字段填充上差异明显。
§4.2 策展做到什么程度
平台对提交的数据做两件事：自动化注释与人工校验。
自动化部分在提交时立刻执行：识别基因片段、检查序列与元数据是否自洽、标注明显的异常。常用自动检查包括采集日期与分子钟估计明显冲突、同一条共识序列里出现多个谱系的标志位点、移码数量异常等。发现问题时，策展人员会给序列打标签并通知提交者，由提交者决定如何处理。
人工部分负责抽样核查与疑难裁定。策展是持续的，提交者可以随时更新自己提交的记录——换用覆盖更好的序列、补充元数据、或申请临时下线以修正错误。
§4.3 不删除，只下架
平台明确承诺：不删除记录。当一条记录被判定为重复或存在明显错误（如样本污染），它会被撤下、不再显示，但底层记录保留。元数据即使在数据被撤下后仍可访问，以保证追溯链不断。
这条规则对使用者的含义是双向的。好的一面：引用过的登录号不会某天消失，论文的可复现性有保障。麻烦的一面：如果你在撤下之前下载过它，你的本地副本会与平台现状不一致，而且平台不会通知你。
§4.4 已知的结构性问题
以下四条不是传闻，是平台自身的规则与声明直接导致的后果。
| 问题 | 成因 | 使用时的应对 |
|---|---|---|
| 不做质量分级 | 平台对序列只做格式与自洽校验，不评估测序质量 | 组装质量、覆盖深度、是否来自临床原始样本，需自己判断 |
| 同一毒株多条记录 | 传代历史不同即视为不同毒株 | 按病毒名与采集日期做一次自己的去重 |
| 字段填充不均匀 | 由提交实验室自行填写，无强制粒度 | 跨国分析只用国家一级；患者字段不齐全时不可当协变量 |
| 数据不回流公共库 | 平台不提供向其他数据库释放数据的机制 | 只用 INSDC 建库会系统性漏掉一部分流感序列 |
第三条值得多讲一句。平台在问卷中给出的字段清单里，人源记录包含患者年龄、性别、健康状况、既往接种史、疫情信息、抗病毒治疗六项，动物源记录包含宿主亚类/科/种、家养状态、健康状况、活体致病性试验、接种状态、所用疫苗株六项。这些字段是可选填写，不是强制。实际使用中，同一分析里往往一半记录有患者年龄、一半没有。
§4.5 一个具体的形状问题：片段数不等于毒株数
新手最常犯的计数错误，是把「片段序列数」当「毒株数」。
2019 年官方海报给出的口径是约 120 万条片段序列、近 30 万毒株，两者相差约四倍。换个角度看，平均每个毒株提交了约四个片段。这个比例本身就说明：大量毒株只提交了部分片段，而部分片段里 HA 段占绝对多数，因为亚型判定、抗原分析、系统发育都从 HA 开始。
对使用者而言，这个结构差异决定了两条完全不同的技术路线：
| 目标 | 应筛的层级 | 预期样本量 | 代价 |
|---|---|---|---|
| 亚型演化与抗原漂移 | HA 单段 | 最大 | 丢失重配信息 |
| 疫苗株匹配与遗传背景 | HA + NA 两段 | 中等 | 无法做全基因组树 |
| 重配与跨段共演化 | 八段齐全 | 最小 | 可能只剩几千株 |
在确定课题的样本量之前，先在这个库里跑一遍「八段齐全」的筛选，是成本最低的尽职调查。
§5 取用层：检索、打包与边界
§5.1 检索的维度
EpiFlu 的网页检索把条件分成基本筛选与附加筛选两组。
| 组别 | 可选条件 |
|---|---|
| 基本筛选 | 型（甲/乙）、H 亚型、N 亚型、乙型谱系、宿主（人/动物/禽/鸡）、大洲、是否已放行、是否本人提交 |
| 附加筛选 | 采集日期区间、提交日期区间、原始实验室、提交实验室 |
| 片段筛选 | 指定必须包含哪几个片段、是否只取完整基因组、最小长度、是否只取本平台上直接提交的记录 |
最后一项「是否只取本平台上直接提交的记录」很关键。库里有一部分是从公共域导入的，这部分数据在 GenBank 也有，可以自由再分发。如果你只需要可再分发的那部分，在这个筛选上勾选「仅直接提交」，就能把可自由再分发的子集单独切出来——但要注意，勾选后的结果是「直接提交的那部分」，不是「可再分发的那部分」，两者不能等同。
§5.2 取数的形态
检索完成后，平台提供两类产出。
一类是序列文件。 导出为 FASTA，序列头按平台规则拼装，包含毒株名、登录号、片段标识。这个头部格式可以直接喂给比对与建树工具，不需要额外清洗。
一类是元数据表。 以表格形式导出，一行一个毒株或一行一个片段（取决于导出选项），列包括病毒名、登录号、型与亚型、宿主、地点、日期、两个实验室。
两类产出配合使用是标准做法：先按元数据筛出毒株清单，再按清单取序列。
§5.3 一个检索的完整流程
1. 注册并登录 platform.gisaid.org
2. 进入 EpiFlu 检索页
3. 设基本筛选：Type=A, Subtype=H5, Host=Avian, Region=Asia
4. 设附加筛选：Collection date 2024-01-01 至 2026-10-01
5. 设片段筛选：Required segments 勾 HA；勾 only complete 视分析目标决定
6. 查看结果数与毒株列表
7. 导出元数据表（用于筛选与去重）
8. 选定毒株，导出 FASTA
9. 生成 EPI_SET 号，记录在论文的数据可用性声明里
第九步是最容易漏、也最难补的一步。EPI_SET 号在检索完成后即可生成，生成为止都不难；等到论文投稿时再回头找当初的检索条件，才真的难。
§5.4 自动化取数的边界
GISAID 没有对外的公共 API。第三方工具（如各类流行病学数据访问器）能登录平台并取数，但走的是模拟浏览器会话的路径，本质仍是「以某个人类用户身份访问」。
平台对此有明确态度：检测到爬虫类自动化程序干扰系统性能时，系统会先启动防御，在部分情况下不经通知直接暂停访问 72 小时；若账号被关联到「使数据流出平台」的行为，同样会被暂停并收到整改要求。
所以自动化不是绝对禁止，但有两条硬线：
一、不能把取数行为做成对平台有压力的高频请求。
二、不能让数据经由你的账号流到平台之外。
第二条是很多「顺手做了个镜像站」的项目折戟的地方。技术上加个公开的下载入口一秒钟的事，协议上则是明确的违约。
§5.5 什么不能做
| 不能做 | 依据 |
|---|---|
| 把序列文件发给未注册的合作者 | 协议第 2(d) 条 |
| 把序列整理成数据集上传到公开托管平台 | 同上，等同于向第三方分发 |
| 把序列放进专利申请 | 注册页明示不得对数据附加限制，包括专利申请 |
| 建一个镜像站点供他人访问 | 协议第 2(b) 条禁止借其他门户提供服务 |
| 用爬虫高频抓取 | 平台会暂停账号 |
| 用 EpiFlu 数据训练出的模型直接发布权重而不做说明 | 协议未直接禁止，但致谢义务仍然适用 |
最后一条是灰色地带，值得单独说清：协议约束的是数据的分发，不直接约束从数据学到的参数。但发表时必须履行的致谢义务并不因「只发布了模型」而消失，而且合作义务（第 2(e) 条）同样适用。做这类工作前，最稳妥的做法是提前与主要贡献实验室沟通。
§6 平台结构与库内关系
§6.1 GISAID 的五个库如何分工
前文已列五个库，这里补上它们之间的关系：它们不是同一份数据的不同视图，而是五个独立的库，各自有独立的登录号前缀体系、独立的策展队列、独立的系统发育页。
对使用者最直接的影响是检索范围。在 EpiFlu 里检索是检索不到新冠序列的，反之亦然。跨病原的比较研究需要分别取数、分别致谢，不能合并成一次检索。
§6.2 与新冠时期那个库的关系
EpiCoV 是 2020 年新增的库，三年间成为全平台规模最大的一个。它在 2025 年经历了一轮收缩：平台停止了向若干外部分析站点供数的固定文件流，理由是这些文件不再被充分使用、持续生成与传输的成本不划算，同时启动了对外部使用情况的合规审计。相关站点在 2025 年 11 月公开披露了供数中断。
这件事对 EpiFlu 有两个间接含义。其一，平台对「数据流出」的态度在收紧，曾经为特定项目开的口子在回收。其二，EpiFlu 从未有过 EpiCoV 那样的外部文件流，流感领域的下游工具（系统发育页、突变注释工具）都是平台自建，因此受这轮收缩的直接影响较小。但它提醒使用者：不要把对平台取数方式的预期，建立在其他库历史上的宽松做法上。
§6.3 库内相关词条
| 相关词条 | 关系 |
|---|---|
| ENA | 核酸序列总档案，流感序列的另一个来源；可自由再分发，但覆盖不全 |
| BV-BRC | 病原基因组库，病毒为主，含流感，做过统一重注释 |
| GISAID EpiCoV | 同平台的新冠库，机制相同、数据不同 |
三条关系的共同点是：它们都是序列的来源，但可再分发性各不相同。在同一个分析里混用这几处数据，最终产物能不能再分发，取决于最严格的那个来源。
§6.4 检索路径建议
- 要最全的流感片段序列 → EpiFlu
- 要可自由分发的流感序列 → GenBank（接受覆盖不全）
- 要现成的谱系树与分支命名 → GISAID 系统发育页、Nextstrain
- 要统一重注释的病毒基因组 → BV-BRC
§7 质量评估与局限
§7.0 阅读本节前需要知道的一件事
EpiFlu 不应该用「数据集」的标准来评价。它没有版本发布、没有训练测试划分、没有质量分级、没有标注规范文档。用这些尺子去量，量出来的每一项都是「缺失」，但缺失的不是它的功能，是尺子选错了。
合适的评价框架是档案与准入机制的框架：它能不能让该进来的数据进来、能不能让进来的人按规则使用、能不能让贡献者得到承认。按这三条看，它的表现和按数据集标准看完全不同。
本节按这个框架逐条列局限，不做价值判断。
§7.1 规模口径的三重不确定
关于 EpiFlu 有多大，公开信息里存在三个层次的数，混用会得出错误结论。
| 口径 | 数值 | 时点 | 覆盖范围 |
|---|---|---|---|
| EpiFlu 单库 | 约 30 万毒株 / 约 120 万片段 | 2019 年官方海报 | 仅 EpiFlu |
| 全平台五库合计 | 二千二百余万条提交 | 2026 年 10 月官网首页 | EpiFlu + EpiCoV + EpiPox + EpiRSV + EpiArbo |
| 单个研究子集 | 视筛选而定 | 各论文自述 | 研究者自己的检索结果 |
第二行那个数常被误当成 EpiFlu 的规模，实际是全平台合计，且其中相当大一部分是新冠序列。EpiFlu 当前没有公开的实时单库计数，想拿到当前规模，唯一办法是登录后在检索页看总数——而那个数随检索条件变化，不是全库总数。
处理原则：引用规模时，明确标注是哪一年的哪一份口径、覆盖的是单库还是全平台。三者不可互相换算。
§7.2 数据质量的边界
平台保证的事和保证不了的事，需要分清。
| 平台保证 | 平台不保证 |
|---|---|
| 记录不会被删除，引用过的登录号始终可查 | 序列的测序质量 |
| 放行后立即对全体注册用户可见 | 组装是否正确 |
| 自动注释会标出明显的自洽性问题 | 元数据是否完整、是否准确 |
| 每条记录有编辑历史 | 同一毒株是否被重复提交 |
第二、四列的内容全部由提交实验室负责。EpiFlu 是一家传递者，它不生成数据，也不为数据的内容背书。
§7.3 五个必须自己处理的问题
一、去重。 同一分离株的不同传代历史会形成多条记录。按病毒名与采集日期做一次自己的去重，是所有下游分析的前置步骤。
二、片段完整性。 前文已述，按目标选片段层级。八段齐全的子集远小于 HA 单段子集。
三、地理精度。 跨国比较只用国家一级；省市级在同一提交方内部可比，跨提交方不可比。
四、患者字段的缺失结构。 人源记录的患者年龄、性别、接种史是可选字段。缺失不是随机缺失——监测体系强的国家填得全，弱的填不全。把这个结构性缺失当随机缺失处理，会引入偏倚。
五、时间的滞后与回填。 一条序列从采集到放行的间隔因国家和事件而异；同时，历史记录会被提交者持续回填与更新。基于某一时点快照的分析，在半年后重跑会得到不同的集合。
§7.4 再分发的法律边界
这是全篇最需要说清的一条。
| 场景 | 是否可行 | 说明 |
|---|---|---|
| 论文中报告统计结果 | 可行 | 需致谢 + EPI_SET |
| 论文附录中列毒株清单与登录号 | 可行 | 这是标准做法 |
| 论文附录中附序列比对结果（含序列） | 有风险 | 比对结果含原始序列，视为分发 |
| 把序列附在预印本补充材料 | 不可行 | 预印本也是公开发布 |
| 把序列上传到公开数据集平台 | 不可行 | 明确的分发 |
| 把模型权重公开 | 灰色 | 协议约束数据，不直接约束参数；致谢义务仍在 |
| 机构内部共享给未注册同事 | 不可行 | 需对方自行注册 |
第三行是最容易出问题的一行。很多人认为「我发的是比对结果，不是原始数据」，但一条比对结果里包含每一条原始序列的碱基，这在实质上就是分发。
§7.5 DAIMS 式评估
按数据管理能力的通用维度做一次评估，结果如下。
| 维度 | 评级 | 依据 |
|---|---|---|
| 标识（ID） | 强 | 毒株级与片段级两级登录号，永久且被期刊接受 |
| 可获取性（A） | 中 | 免费但需实名准入，不能匿名取用，不能批量镜像 |
| 可互操作（I） | 中 | 序列格式标准，元数据字段命名与 INSDC 系不完全对齐 |
| 可复用（R） | 中 | 谱系与亚型字段有统一注释；但无质量分级、无版本号 |
| 可溯源性 | 强 | 每条记录有原始实验室、提交实验室、编辑历史 |
| 可再分发 | 无 | 协议明确禁止 |
| 更新频率 | 强 | 放行即时可见，提交者可随时更新 |
这张表里「可再分发」一列为「无」是关键信息。按开放数据的通用标准看，这是一个明确的扣分项；按流感监测的实际需求看，这正是它能收到别处收不到的序列的原因。同一事实，两套标准给出相反的评价。
§7.6 外部验证：三条可自行核对的路径
| 核对项 | 怎么做 |
|---|---|
| 某毒株是否真在库里 | 用 EPI_ISL 号在平台检索页直接查，或走平台对单个登录号的深链接 |
| 某篇论文的数据集能否复现 | 找论文里的 EPI_SET 号，在平台打开，比对毒株数 |
| 某亚型当前是否有新增 | 看平台系统发育页对应分支的最近样本 |
三条都不需要额外工具，只需要一个可用的账号。
§8 版本、生态与沿革
§8.1 没有版本号这件事
EpiFlu 没有发布版本。它不是「v3.2 收录了多少条」，而是「今天这个库里有什么」。记录可以随时被提交者更新，序列可以被撤下再放回。
这对可复现性构成直接挑战，但影响比想象中小：因为记录不删除，登录号始终有效；因为 EPI_SET 固化检索集，同一批毒株可以被精确定位。真正不可复现的是「某一天的全库快照」——那个东西不存在。
§8.2 平台的技术沿革
| 时间 | 事件 |
|---|---|
| 2006 年初 | H5N1 序列共享受阻，意大利兽医病毒学家 Ilaria Capua 拒绝把非洲首例 H5N1 序列放入封闭库，转而公开 |
| 2006 年 8 月 | 《自然》刊出七十余位科学家联署的通信，提出建立共享禽流感数据的全球联盟，GISAID 这一缩写由此产生 |
| 2006 年 12 月 | GISAID 作为组织成立 |
| 2008 年 5 月 | 平台与 EpiFlu 在第六十一届世界卫生大会期间发布 |
| 2009 年 | 甲型 H1N1 大流行，EpiFlu 成为各国追踪新病毒演化的主要场所 |
| 2010 年 | 德意志联邦共和国成为平台与 EpiFlu 的官方托管方 |
| 2013 年 | 中国科学家在首例人感染 H7N9 后即刻释放序列，被视为共享机制的标志性时刻 |
| 2019 年 | 数据库应用 v1.1 发布海报，给出约 120 万片段、近 30 万毒株的口径 |
| 2020 年 | 新增 EpiCoV 库，承接新冠序列 |
| 2022 年 | 新增 EpiPox 库，承接猴痘序列 |
| 2025 年 | 收缩对外文件供数，启动合规审计 |
§8.3 技术栈
平台的数据库应用最早由德国马克斯·普朗克信息学研究所开发，底层基于 Oracle 与一家德国公司的商业系统组件。应用层经历的迭代（2019 年海报标注为 v1.1，同期在开发面向更多数据类型的新版本）说明这个库不是静态的档案柜，而是持续在改的软件系统。
对使用者而言，技术栈的唯一现实含义是：界面与导出格式会变，但登录号体系与元数据字段的语义保持稳定。 写脚本对接平台时，绑死在界面元素上迟早要重写，绑在字段语义上不会。
§8.4 生态位：它站在哪个位置
流感的数据链条上，EpiFlu 处在中段。
采样与测序 汇聚与准入 分析与展示
───────── ────────── ──────────
国家流感中心 → EpiFlu → 系统发育页 / 突变注释工具
合作中心 （GISAID 平台） 学术研究与疫苗株建议
禽类参考实验室 第三方下游分析
上游是各国监测网络，下游是平台自建的分析工具与学术研究。它不做原始测序，也不做终端的公共卫生决策，它做的是汇聚与准入这一环。这一环的价值在于：没有它，上游的数据会散在各实验室与各公共库，下游的分析要么样本不全，要么无法致谢。
§8.5 它为何能持续
一个不收数据费、不卖数据、还要养策展团队与服务器的库，靠什么活下来？这个问题回答不了，前面所有的规模数字都只是纸面。
第一层是托管。 2010 年起，德意志联邦共和国担任平台的官方托管方，这一安排把服务器的存续从「项目经费」变成了「国家承诺」。这是它区别于大多数学术数据库的地方——多数数据库的寿命绑定在某个课题的结题日上。
第二层是公私合作。 平台与多国公共卫生机构、学术机构建立了伙伴关系，官网列举的伙伴国家包括阿根廷、巴西、中国、刚果共和国、埃塞俄比亚、印度尼西亚、马来西亚、俄罗斯、塞内加尔、新加坡、南非。这些伙伴既是数据来源，也是机制的外部支持者。
第三层是刚性依赖。 世界卫生组织的流感疫苗株半年度建议，其依据的序列数据大量经由这个平台流转；各国流感中心与禽类参考实验室的日常工作流程里有它的位置。一个环节一旦被流程依赖，替换成本就不再是技术问题。
第四层是互惠预期的自我实现。 提交者愿意交，是因为相信别人也交、且自己会被致谢；使用者愿意守规则，是因为不守就失去访问权。这套机制没有强制执行力之外的保障，它的稳定来自参与者的持续预期一致——也因此，任何一次对规则的收紧或放松，都会波及整个网络的信任。
§8.6 一个需要正视的争议面
这个库的治理结构在外部有过公开质疑，主要集中在决策的集中度、经费与治理的透明度，以及访问权被暂停时的申诉渠道。同类质疑也出现在 2025 年那轮对外供数收缩之后。
这些质疑与本文的事实陈述并不冲突：一个库可以在数据覆盖上无可替代，同时在治理上受到批评。使用者在做依赖决策时，应把「治理集中带来的可用性风险」作为一个独立的评估项——例如，关键项目是否需要保留一份在 GenBank 上的对照数据集，以备不测。
§9 使用指引
§9.1 三种角色的路径
| 角色 | 第一步 | 关键动作 | 容易忽略 |
|---|---|---|---|
| 做谱系演化的研究者 | 注册，等审核 | 按 HA 段筛，按 EPI_SET 固化检索集 | 忘记生成 EPI_SET，投稿时补不回来 |
| 做监测预警的公共卫生人员 | 用机构邮箱注册 | 定期检索新增，关注系统发育页的新分支 | 忽略禁运标记，提前公开了禁运数据 |
| 做数据工程的开发者 | 明确合规边界 | 把取数做成低频、有缓存、只在内部使用 | 把数据顺手做成对外接口 |
§9.2 最小工作流
1. 明确问题 → 选片段层级（HA 单段 / HA+NA / 八段齐全）
2. 明确时间窗与地理范围
3. 设计检索条件，先在平台上跑一次看结果量级
4. 结果量级合适才导出；量级过大先缩窗口
5. 导出元数据表 → 去重（按病毒名 + 采集日期）
6. 导出 FASTA → 与去重后的清单对齐
7. 生成 EPI_SET，抄进项目文档
8. 建树/统计/建模
9. 写致谢与数据可用性声明
10. 发表前再核对一次：涉及的毒株是否都在致谢表里
第十步是很多人翻车的地方。用了几千个毒株，致谢表的生成往往依赖平台导出的清单，一旦中途换过检索条件、用过两批数据，最终致谢表就会与实际的毒株集合不一致。
§9.3 在 AI 流程中的位置
| 环节 | EpiFlu 的角色 | 注意 |
|---|---|---|
| 预训练语料 | 不适合 | 不能分发，无法打包成公开语料 |
| 领域微调 | 可以，但需内部隔离 | 训练数据不能外传，模型发布需说明来源与致谢 |
| 特征工程 | 适合 | 谱系、亚型、宿主、时间都是平台统一注释的高质量标签 |
| 评测基准 | 需谨慎 | 无官方划分，自建测试集要避免与训练集重叠 |
| 生产环境实时推断 | 不适合 | 平台无对外 API，实时性靠人工 |
这五行里，第三行是它被低估的用途：平台对谱系与亚型的统一注释，省掉了大量人工归类的工作，而且这套注释在全世界是同一套语言。
§9.4 三个「不要做」
一、不要把「能下载」当成「能分发」。 下载是使用，分发是另一件事。协议区分得很清楚。
二、不要把平台总量当单库规模。 五个库的合计数字与 EpiFlu 一库的规模差着一个数量级。
三、不要只查 EpiFlu 就声称「全部流感序列」。 公共域档案里有一部分序列不在 EpiFlu，反过来 EpiFlu 里也有大量序列不在公共域。要做全集，两处都要查、并按病毒名与日期去重。
§10 AI 使用声明
| 项 | 声明 |
|---|---|
| 性质 | 受准入协议约束的病毒基因序列库，非开放数据集 |
| 可用于 | 领域研究、谱系分析、监测预警、模型内部训练 |
| 不建议用于 | 公开预训练语料、可再分发数据集、实时生产推断 |
| 伦理 | 人源记录含年龄性别等去标识字段，组合后在小群体下可能构成间接识别风险 |
| 引用 | 正文脚注 + 致谢段 + EPI_SET 号，三者缺一不可 |
| 版本 | 无全库版本号，以检索日期与 EPI_SET 为准 |
| 状态 | 持续更新，记录可更新或下架但不可删除 |
| 再分发 | 协议禁止；统计结果可发表，原始序列不可转手 |
常见误读（避坑清单）
| 常见说法 | 实际情况 | 证据 |
|---|---|---|
| 「GISAID 是个开放数据库，跟 GenBank 差不多」 | 免费但需实名注册与签协议，禁止再分发 | 注册页与协议第 2(b)(d) 条 |
| 「GISAID 一共两千多万条，就是 EpiFlu 的规模」 | 那是五个库的合计；EpiFlu 单库口径约 120 万片段 | 官网首页总量 vs 2019 年 EpiFlu 海报 |
| 「EpiFlu 里是原始测序数据」 | 只有已组装的片段，读段从未入库 | 平台字段与上传流程 |
| 「下载后可以放到自己的服务器给团队用」 | 只允许已注册用户本人使用，建镜像属违约 | 协议第 2(b) 条 |
| 「发论文只要提一句 GISAID 就行」 | 须逐一背书原始实验室与提交实验室，并给 EPI_SET | 官方引用与致谢指南 |
| 「Yamagata 系还有大量新序列」 | 2020 年后全球检出骤减，该系新增记录明显变少 | 平台系统发育页与公开监测报告 |
| 「用机构邮箱和用 QQ 邮箱没区别」 | 公共邮箱会显著降低审核优先级 | 注册页明示 |
| 「同一毒株只有一条记录」 | 传代历史不同即记为不同毒株，需自行去重 | 2019 年 EpiFlu 技术海报 |
| 「EpiFlu 的数据会自动同步到 GenBank」 | 平台明确不提供向其他库释放数据的机制 | 官方 FAQ |
| 「先把数据抓下来，合规问题以后再说」 | 爬虫触发防御后账号会被不经通知暂停 72 小时 | 官方 FAQ |
FAQ
Q1：EpiFlu 要钱吗？
不要。注册、检索、下载全部免费。收费的是时间——注册要等人工审核，用公共邮箱会更久。
Q2：注册需要什么？
真实姓名、机构、职务、地址与邮箱，并逐条接受数据库访问协议。官网建议用机构邮箱，明确说明 Gmail、Yahoo、QQ、126、163 等公共邮箱会降低审核优先级。
Q3：一个账号能用几个库？
五个都能用。EpiFlu、EpiCoV、EpiPox、EpiRSV、EpiArbo 共用一套账号与一份协议。
Q4：能不能一次性把全库下载下来？
技术上可以，协议上不建议，平台上会拦。全库抓取会触发反爬防御，账号可能被不经通知暂停 72 小时。正确做法是按研究目的做一次有边界的检索。
Q5：能不能把序列发给没注册的同事？
不能。协议第 2(d) 条禁止向协议授权用户以外的第三方分发。正确做法是让同事自己注册。
Q6：论文里的数据可用性怎么写？
给 EPI_SET 号，或者给平台为这个集合生成的 DOI。这是唯一能让别人原样复现你那份检索集的写法。
Q7：库里有多少条序列？
EpiFlu 单库的官方口径是 2019 年的约 120 万条片段、近 30 万毒株。平台总量是五个库合计，不能当作 EpiFlu 的规模。
Q8：有没有原始测序读段？
没有。库里只有已组装并注释的基因片段，读段在测序实验室或 INSDC 的读段档案里。
Q9：数据会自动同步到 GenBank 吗？
不会。平台明确不提供向其他数据库释放数据的机制。这也是只用 GenBank 建库会漏掉一部分流感序列的原因。
Q10：能不能用它训练模型然后开源？
协议约束的是数据分发，不是模型参数。但致谢义务不因只发布模型而消失，且协议要求与原始实验室合作。做这类工作前建议先与主要贡献实验室沟通。
Q11：为什么我引用的毒株在平台上搜不到了？
可能被提交者撤下以修正。平台不删除记录，元数据仍可查，但序列可能在修正期间不可见。
Q12：用哪个片段做分析最合适？
看目标。亚型演化和抗原漂移用 HA 单段，样本量最大；疫苗匹配用 HA 加 NA；重配分析必须用八段齐全的子集，量会小很多。
术语表
| 术语 | 解释 |
|---|---|
| EpiFlu | GISAID 平台下的流感病毒基因序列库 |
| GISAID | Global Initiative on Sharing All Influenza Data，2006 年成立的共享倡议 |
| DUA / DAA | 数据库访问协议，注册时必须签署的法律文本 |
| EPI_ISL | 毒株级登录号，标识一次分离 |
| EPI 片段号 | 单个基因片段的登录号 |
| EPI_SET | 一次检索的固化标识，附 DOI，用于论文复现 |
| 隔离株 / 毒株 | 一次分离得到的病毒培养物，含传代历史 |
| H / N 亚型 | 血凝素与神经氨酸酶的抗原分组编号 |
| 谱系 | 乙型流感的 Victoria 与 Yamagata 两大分支 |
| 重配 | 两株病毒共感染时交换片段，产生新组合 |
| HA 段 | 血凝素基因片段，亚型判定与抗原分析的依据 |
| NA 段 | 神经氨酸酶基因片段，抗病毒药物耐药分析的依据 |
| pdm09 | 2009 年大流行的甲型 H1N1，单独列为一类 |
| 策展 | 平台对提交数据做自动化注释与人工校验 |
| 临时发布禁运 | 提交者设置的窗口，期内第三方不得公开发表基于该数据的成果 |
| 原始实验室 | 采集样本的实验室，发表在致谢中列首位 |
| 提交实验室 | 完成测序并向平台上传达实验室 |
| 疫源溯源 | 通过进化树与地理信息推断传播路径 |
| GISRS | 世界卫生组织全球流感监测与应对系统 |
| INSDC | 国际核苷酸序列数据库协作组织，含 GenBank、ENA、DDBJ |
附录 A：速查卡
| 问题 | 答案 |
|---|---|
| 全名 | GISAID EpiFlu Database |
| 上线 | 2008 年 5 月 |
| 托管方 | 德意志联邦共和国（2010 年起） |
| 运营方 | Freunde von GISAID e.V. |
| 单库规模 | 约 30 万毒株 / 约 120 万片段（2019 官方口径） |
| 平台总量 | 五个库合计，二千二百余万条（2026-10 官网） |
| 组织层级 | 毒株（EPI_ISL）→ 片段（最多 8 段） |
| 覆盖 | 甲型全 H/N 亚型；乙型 Victoria 与 Yamagata |
| 宿主 | 人、禽、猪、马、犬、环境等 |
| 访问 | 注册 + 签协议，免费 |
| 再分发 | 禁止 |
| 原始读段 | 不含 |
| 全库打包 | 不提供 |
| 版本号 | 无 |
附录 B：五个常见检索场景
| 场景 | 筛选条件组合 | 预期难点 |
|---|---|---|
| 追踪禽流感跨洲传播 | 型=甲、H=5、宿主=禽、大区=亚洲 | 地理粒度不均，跨年比较要固定粒度 |
| 评估耐药位点 | 祖先=人、H=1、N=1、含 NA 段 | H1N1pdm09 需单独选，不与季节性合并 |
| 做乙型谱系演化 | 型=乙、谱系=Victoria | Yamagata 近年样本少，时间轴会断 |
| 疫苗株与流行株比对 | 提交实验室=各合作中心 | 候选株信息公开有额外限制 |
| 全基因组重配分析 | 片段筛选=八段齐全 | 样本量骤减，可能不足以建树 |
编辑说明
核验时间：2026-10-29。
核验方式：读取 GISAID 主站首页、使命页、历史页、注册页、数据库访问协议原文、官方 FAQ、引用与致谢指南、FAIR 原则说明页；读取 EpiFlu 相关技术海报（2019 年）与第三方学术文献中对该库的描述；与库内 ENA、BV-BRC 两篇做定位对照。
未做：未登录平台做全库计数，未下载任何序列，未对任何子集做质量评估。因此正文中的规模数字采用的是官方公开口径，不包含自行统计。
未能独立核实：EpiFlu 当前（2026 年）的单库实时规模。官方近年不再单独公布该数，平台首页的合计数字无法拆分为单库。
数字口径提醒：约 30 万毒株与约 120 万片段来自 2019 年官方海报；二千二百余万条来自 2026 年 10 月平台首页、为五个库合计。两组数字不同时点、不同范围，不可互相换算。
最后更新：2026-10-29
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- sra — 共享标签：基因组学与多组学 / 公共卫生与流行病学 / 测序数据
- metasub — 共享标签：基因组学与多组学 / 公共卫生与流行病学 / 测序数据
- impc — 共享标签：基因组学与多组学 / 公共卫生与流行病学
- alphamissense — 共享标签：基因组学与多组学 / 公共卫生与流行病学
- gnomad — 共享标签：基因组学与多组学 / 测序数据
- bioproject — 共享标签：基因组学与多组学 / 测序数据
- gmrepo-v3 — 共享标签：基因组学与多组学 / 公共卫生与流行病学 / 测序数据
- china-map — 共享标签：基因组学与多组学 / 公共卫生与流行病学 / 测序数据
- uniprot — 共享标签：基因组学与多组学 / 测序数据
- 1000-genomes — 共享标签：基因组学与多组学 / 测序数据
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
