FastQ 文件格式详解归纳总结
做 NGS 分析的人，每天都要跟 FastQ 打交道。说白了它就是测序仪吐出来的原始数据格式。我刚开始入行时，觉得它不就是四行嘛，结果被坑过几次之后才发现——细节里全是门道。
四行结构，缺一不可
每一条测序读长在 FastQ 里都占 4 行。我就按顺序给你拆开讲。
- 第 1 行：以
@开头，是序列标识符。通常包含仪器名称、flowcell 编号、lane、tile、X/Y 坐标等信息。 - 第 2 行：碱基序列，由 A/T/C/G/N 组成。
- 第 3 行：以
+开头，后面可以重复第 1 行的标识符（也可以留空）。 - 第 4 行：每个碱基对应的质量分数编码，长度与第 2 行完全一致。
核心原则：第 2 行和第 4 行长度必须相等，否则整个文件就是坏的。
举个真实例子，来自 Illumina NextSeq 500 的一条 read：
@EAS139:136:FC706VJ:2:2104:15343:197393
CTACGTGATCGATCGATCGATCAGCTAGCATCGATCGA
+
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII质量分数编码：Phred+33 vs Phred+64
第 4 行的符号不是乱码，它们对应着 ASCII 码，背后是 Phred 质量分数。我见过很多新手对着 I 和 F 发懵，其实规则很简单。
| 编码体系 | ASCII 范围 | 质量分数范围 | 常见平台 |
|---|---|---|---|
| Phred+33（Sanger） | 33 – 126 | 0 – 93 | Illumina 1.8+, Ion Torrent, PacBio, ONT |
| Phred+64（旧版） | 59 – 126 | 0 – 62 | 早期 Illumina 1.3 – 1.7 |
换算公式很简单：Q = ASCII 码值 − offset。Phred+33 的 offset 是 33，Phred+64 的 offset 是 64。比如字符 I 的 ASCII 是 73，减去 33 得到 Q40，说明这个碱基的错误概率只有万分之一。
我的习惯：拿到新数据后，先看一眼第 4 行第一个字符是啥。如果看到 @ 或 ! 那肯定是 Phred+33，如果看到 B 或 C 就要小心了，可能是 Phred+64。
解析工具与验证
你可以用 head -n 40 直接看前 10 条 read 确认格式。我常用这条命令快速判断：
# 查看前 4 行的第 4 行第一个字符的 ASCII 码
head -n 4 sample.fastq | tail -n 1 | head -c 1 | od -An -tuC如果输出 73，那就是 I，对应 Phred+33。如果输出 88，那是 X，对应 Phred+64。嗯，这个方法屡试不爽。
曾经踩过的坑：有一次我从公共数据库下载了一个大项目，FastQ 文件以 .fastq.gz 命名，我用标准流程跑完比对后发现 Q20 比例异常低。后来检查发现这批数据是 Illumina 1.5 旧格式，用的是 Phred+64，但我工具默认按 Phred+33 解析，导致所有质量分数都偏移了 31 个点。从那以后我养成了先验证编码体系的习惯。
SVG：FastQ 格式结构图
常见变体与注意事项
- 标识符重复：部分工具要求第 1 行和第 3 行的 @ 和 + 后面的内容完全一致，但实测中很多 FastQ 第 3 行只有
+没内容，照样能读。 - 多行序列：标准规定第 2 行和第 4 行只能各占一行。但某些老版本格式允许折行，碰到这种情况建议先用
seqtk或fastx_trimmer归一化。 - 压缩格式：绝大多数 FastQ 采用 gzip 压缩，扩展名
.fastq.gz。解压后检查文件完整性，不要直接用zcat硬灌进不支持管道的工具。
避坑总结：我曾经在处理一个来自 NCBI SRA 的批次数据时，发现部分文件第 4 行出现 ! 字符（ASCII 33），对应 Q0，理论上不可能出现。后来查到来源是某台 MiSeq 在 calibrator 阶段出了故障。这种带 Q0 的碱基在分析前必须过滤掉，否则会在变异检测中引入大量假阳性。
说到底，FastQ 就这么点东西，但格式的规范性会直接影响下游所有分析的质量。花十分钟确认编码、行数、长度，比花一天排查莫名其妙的结果要划算得多。