常见FASTQ命名规则概述：Illumina、SRA、自定义
很多人第一次接触FASTQ文件，往往是被那串又长又怪的文件名搞懵的。说白了我当初也一样。你下载一个测序数据包，解压出来全是SampleName_S1_L001_R1_001.fastq.gz这样的名字，到底代表什么？
我在这行摸爬滚打多年，遇到过各式各样的命名方式。标准化命名是好事，但说实话，现实世界的数据命名总是带点“惊喜”。今天就带你梳理三种最常见的命名规则：Illumina官方规则、SRA公共库规则、以及各实验室自定义规则。
Illumina官方命名规则
这是测序仪器直接吐出来的命名。规整、结构化、信息量大。但也是我职业生涯初期栽过跟头的地方。
一个典型的Illumina双端FASTQ文件名长这样：
SampleName_S1_L001_R1_001.fastq.gz
SampleName_S1_L001_R2_001.fastq.gz拆开来看，每个部分都有自己的含义：
| 字段 | 示例 | 含义 |
|---|---|---|
| SampleName | SampleName | 样本名称（用户自定义） |
| S1 | S1 | 样本编号（Sample ID） |
| L001 | L001 | Lane编号（流动槽泳道） |
| R1 | R1 | 读取方向（Read 1 / Read 2） |
| 001 | 001 | 分片编号（分卷） |
关键点：L001这个字段是批次信息的关键来源。同一个测序批次的样本，Lane编号一般相同。但要注意，如果你用的是HiSeq 4000或NovaSeq这类平台，可能会有多个Lane，但有时候样本也会在同一个测序run中跨Lane。
还有一种更完整的命名，包含仪器和run信息：
170407_NB551000_0034_AHL5JMBGX5_S1_L001_R1_001.fastq.gz拆解一下：
- 170407：测序日期（年-月-日）
- NB551000：仪器名称（比如MiSeq、NextSeq）
- 0034：Run编号
- AHL5JMBGX5：Flowcell ID（每个flowcell唯一）
- S1：样本编号
- L001：Lane编号
- R1：Read方向
- 001：分片编号
我自己在实际项目中发现，有些数据中心交付数据时会把前面的日期和run信息去掉，只保留SampleName_S1_L001_R1_001.fastq.gz这种简写版本。这样做固然清爽，但丢了批次信息——你无法从文件名反推出这批数据是在哪台机器、哪个run上产的。
避坑提醒：我曾经碰到过一个案例，客户提供的FASTQ文件名完全符合Illumina格式，但实际内容却是双端序列被合并成了单端。别只信文件名，必要时用zcat或seqkit验证一下reads数量和方向。
SRA命名规则
从NCBI SRA下载的数据，命名就比较简单了。I你从SRA下载后，得到的一般是SRRXXXXXXX这种格式：
SRR12345678_1.fastq
SRR12345678_2.fastq或者有时是分卷的：
SRR12345678_1.fastq.1
SRR12345678_1.fastq.2这里的关键是：
- SRR：SRA Run编号前缀（Sequence Read Archive Run）
- 数字：Run的唯一标识
- _1 / _2：Read方向（Read 1 / Read 2）
- .1 / .2：分卷编号（有时出现）
这种命名其实没什么批次信息可言。它只是SRA系统内部的一个唯一标识。真正的批次信息（比如项目、样本、实验等）需要从SRA元数据中查找。
我记得有一次在NCBI上下载了一批SRA数据，文件名全是SRR********开头的。想根据文件名快速筛选某个特定批次，根本做不到。最后只能去查SRA Run Selector里的metadata表格。
我建议：如果你经常用SRA数据，可以写个小脚本，把SRA的元数据（SRA号、样本ID、项目ID、测序平台等）拉下来存成CSV，然后按照你需要的批次字段去匹配文件名。省得一个个手动查。
SRA命名的一个变体是ENA（欧洲核苷酸档案）的格式——有时数据会变成ERRXXXXXXX或DRRXXXXXXX，前缀不同但逻辑完全一样。
自定义命名规则
这个领域就五花八门了。你做项目时，可能会遇到这样的情况：
Proj001_SampleA_Tumor_WGS_R1.fastq
Proj001_SampleA_Tumor_WGS_R2.fastq或者：
20240301_HuLab_MouseLiver_KO_rep1_R1.fastq自定义命名的好处是灵活，可以高度定制。但坏处也很明显——没有统一标准，别人（甚至未来的你自己）很难猜出每个字段的含义。
我自己比较推崇的“好习惯”是这样的：
- 使用下划线分隔字段，不要用空格或点号（点号容易和扩展名混淆）
- 固定字段顺序，例如：项目_样本_处理_批次_方向
- 日期前置于文件名开头，方便按时间排序
- 方向标记统一：R1/R2、_1/_2、F/R等都可以，但要保持一致
- 避免使用特殊字符：比如$、%、#、空格，这些在脚本处理时容易出问题
举个例子，你可以这么定：
YYYYMMDD_Project_Sample_Batch_Rep_Treatment_R1.fastq.gz比如：
20240301_HuLab_NormalLiver_Batch01_rep1_WT_R1.fastq.gz避坑提醒：我曾经接手过一个项目，数据文件名长这样——sampleA.fastq、sampleB.fastq。问前同事有什么规则，他说“自己猜”。结果同样的样本名出现在不同批次，反复跑分析才发现搞混了。命名规则一定要写在实验记录里，并且版本控制好。
命名规则对比与选型
三种命名方式，其实各有适用场景。我整理了一个对比表：
| 维度 | Illumina | SRA | 自定义 |
|---|---|---|---|
| 批次信息密度 | 高（含Lane、Flowcell、Run） | 低（只有SRR ID） | 灵活（取决于设计） |
| 标准化程度 | 高（全球通用） | 高（NCBI官方） | 低（完全自定义） |
| 脚本解析难度 | 中等（需解析固定格式） | 简单（按下划线切分即可） | 高（必须知道字段含义） |
| 跨平台兼容 | 好（主流工具都支持） | 好 | 差（需额外映射） |
你问我在实际项目里怎么选？
如果是公司级别的生产环境，我二话不说选Illumina标准格式，最多加点自定义前缀。如果是公共数据，那就老老实实走SRA元数据。如果是小团队私有的项目，我倾向于半自定义方案——用Illumina的骨架，加上自己的项目标识。这样既有可解析的Lane/Flowcell信息，又保留了项目上下文。
嗯，说白了就是别把鸡蛋放在一个篮子里。结构化的命名是你后续批量处理的第一道保险栓。
你现在脑子里应该有个大致框架了。接下来我们会深入具体的解析方法——有了命名规则，怎么用脚本把那些字段“挖”出来。相信我，这不是什么枯燥的理论课，全是实战技巧。