FASTQ 格式简介：结构、质量分数、序列标识符

大家好，我是老赵，干生物信息这行十几年了。今天咱们聊点最基础但也最容易被坑的东西——FASTQ 格式。你想想看，每次从测序仪拿到数据，打开一看全是 @ 和 +，质量分一串乱码似的符号，能一眼看懂吗？我刚开始也懵，后来被坑过几次，才彻底搞明白。

1. 什么是 FASTQ 格式

说白了，FASTQ 就是测序仪的“原生格式”，它把每条序列的碱基内容和对应的碱基质量打包在一起。一条记录占四行，没有多余的空行。我见过很多新手把 FASTQ 当成 FASTA 来解析，结果丢质量信息——这种错在项目里特别致命。

为什么要用 FASTQ？因为测序不是 100% 准确，每个碱基都有个“可信度”打分。比如你看到 A，但它可能是机器误读的。质量分数就是告诉你“这个 A 正确的概率有多大”。嗯，这里有个关键点：质量分数不是直接写概率，而是用 ASCII 码编码的。

2. FASTQ 记录结构

一条记录就四行，我列个模板：

@EAS139:136:FC706VJ:2:2104:15343:197393 1:Y:18:ATCACG
CTACGTAGCTAGCTAGCTAGCTAGCTAGCTAGCTAGCTAGCTAGCTAG
+
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

四行分别是：

• 第1行（标识符行）：以 @ 开头，紧跟序列标识符，可以包含设备ID、流道坐标、barcode 等元信息。
• 第2行（序列行）：纯碱基字母（A/T/C/G/N），长度与质量行严格一致。
• 第3行（分隔行）：以 + 开头，后面可以重复第1行的标识符（通常为空）。
• 第4行（质量行）：每个碱基对应一个 ASCII 符号，符号的 ASCII 值减去 33 就是该碱基的 Phred 质量分数。

3. 序列标识符：头行里的玄机

@ 后面的字符串不是随便写的。不同的测序平台有自己的命名规范。比如 Illumina 的典型格式：

@EAS139:136:FC706VJ:2:2104:15343:197393 1:Y:18:ATCACG

用冒号分隔的字段含义通常为：

为什么我要你注意这个？因为很多下游分析工具（比如 bwa、STAR）需要从标识符里提取 lane、tile 等数据做偏差校正。我记得有一次做 ChIP-seq 去重，发现重复率异常高——后来查出是标识符里的坐标字段被我截断了。所以啊，解析标识符千万别大意。

4. 质量分数编码

质量行看起来是乱码，其实是 ASCII 符号。其对应关系如下：

• Phred 质量分数 Q = -10 log10(P)，P 是碱基错误的概率。
• ASCII 码值 = Q + 33（Sanger 编码，最常用）。

举个例子：ASCII 为 'I' (73) 时，Q = 73 - 33 = 40，对应错误概率 0.0001%。质量越高，符号越靠后（比如 'I' 比 'F' 质量高）。

5. 常见质量编码方案对比

现在绝大多数公开数据都用 Sanger（Offset 33）。但你从 NCBI SRA 扒下来的古老数据集偶尔还会碰到 64，必须先用 fastq_detect 或 seqtk test 自动检测。我个人习惯是：写 pipeline 时第一步就用 Python 脚本扫描前1000条记录，算一下质量行字符的 ASCII 最小值，如果小于 64 就是 33，否则可能是 64。这样保证不踩坑。

6. 避坑指南

总结合并，我把自己踩过的雷列一下：

• 头行 @ 和 + 数量不匹配：有次我从某平台导出 FASTQ，发现 + 行后面跟了标识符，导致解析器崩溃。解决方案：写脚本时放开 + 行格式，只取前两个字符判断。
• 碱基序列和质量行长度不一致：通常是 read 末端质量差被截断造成的。我建议读入后立刻断言长度相等，否则抛异常。
• Windows 换行符：\r\n 会让某些工具误读。我会用 dos2unix 或者 Python 的 open(newline='') 统一处理。
• 压缩文件内多条记录混在一起：比如 gzip 后丢包，这时候用 zcat | wc -l 检查行数是否是4的倍数。

好了，以上就是 FASTQ 格式最核心的基础。你掌握了四行结构、标识符含义和质量编码规则，后面章节聊文件名抽取和批次解析时，就能理解那些数据是怎么来的了。