企业官网建设流程全解析

先说个真实场景。实验室新到一批粪便样本的宏基因组双端数据，下机之后直接丢进组装流程，结果 contig N50 只有几百 bp，物种注释里一堆环境样本常见的杂菌，开会一分析才发现问题出在最前面那一步——原始数据里的接头、低质量碱基、测序仪特有的 polyG 假象全都原封不动进了下游。宏基因组流程里，质控（QC）看起来是最没有技术含量的一环，一条 fastp 命令十秒钟跑完，但恰恰是这一步的参数取舍，决定了后面组装、分箱、物种分类和功能注释的上限。Fastp 是目前用得最广的质控工具之一，速度快、依赖少、报告直观，但它对宏基因组的适配并不是"默认参数一跑就完事"。这篇内容围绕宏基因组流程中的 Fastp 质控环节展开，把参数背后的逻辑、命令的写法、报告的读法、以及我实际踩过的坑全都摊开来讲，适合刚接手宏基因组流程的同学，也适合已经跑过几批数据、但总觉得结果不太对劲的人对照检查。

1. 先搞清楚宏基因组的"脏"和单基因组的"脏"不是一回事

1.1 下机原始数据里到底混进了什么

很多人对质控的理解停留在"把质量低的碱基切掉"，但原始 fastq 里混着的东西远不止低质量碱基。第一类是测序接头，当插入片段长度小于读长时，测序仪会一直读到接头序列，这部分碱基在比对时会形成软剪切甚至错误比对，在组装里会形成假的连接。第二类是低质量碱基，尤其是 read 3' 端，随着测序循环推进，荧光信号衰减、相位漂移累积，质量值会明显下滑，这类碱基的错误率可能高达百分之几。第三类是测序仪特有的系统性假象，比如双色荧光系统在信号缺失时会判读为 G，于是出现一长串 polyG，这跟样本本身没关系，纯粹是仪器特性。第四类是N 碱基，当判读置信度不足时会输出 N，连续的 N 在组装时会直接断开。第五类是低复杂度序列，比如连续的 AT 重复、微卫星序列，这类序列在多物种混合的宏基因组里特别容易造成错误拼接。

还有一类容易被忽略的，是人为引入的污染，比如建库过程中的引物二聚体、实验室环境微生物、试剂自带的应用背景菌群。这一类 Fastp 处理不了，属于去宿主和前处理环节要解决的问题，但在看质控报告时要心里有数，不能把污染当成真实信号。我见过有人质控后 clean ratio 只有 60%，第一反应是参数设太严，结果是文库本身浓度不够、引物二聚体占比过高，这种数据再怎么调参数也救不回来，只能重做。

1.2 宏基因组比单基因组更挑质控策略的三个原因

第一个原因，宏基因组没有"参考基因组质量"这个安全网。单基因组测序里，哪怕有几个错误碱基，比对到参考基因组上还能靠比对算法纠回来。宏基因组绝大多数样本没有完整参考，下游要么 de novo 组装，要么靠 k-mer 分类，错误碱基会直接变成组装断裂点或者假阳性物种信号。低丰度物种本来 reads 就少，一条错误 reads 就可能让某个物种在分类结果里凭空出现或者彻底消失。

第二个原因，宏基因组的物种丰度分布极度不均。高丰度物种可能占 50% 以上，低丰度物种可能只有万分之几。质控参数如果偏严，先被砍掉的就是低丰度物种那部分 reads，因为它们质量分布往往和高丰度物种不一样。这里有个反直觉的点：质控过度比质控不足更危险。质控不足顶多是下游噪音多一点，还能靠算法过滤；质控过度直接抹掉了低丰度信号，事后无从恢复。

第三个原因，宏基因组的数据量大、样本批次多。一个项目动辄几十上百个样本，每个样本几个 GB，批次之间可能用了不同的建库试剂盒、不同的测序平台。Fastp 的处理速度和批次一致性直接影响整个流程能不能按时交付。我自己的经验是，宏基因组的质控参数宁可按批次统一、略微宽松，也不要每个样本单独调参——单独调参看似精细，实际上引入了不可控的批次效应，后面做差异分析时根本说不清是生物学差异还是质控差异。

1.3 Fastp 在这个流程里的位置与边界

Fastp 的定位很明确：在比对之前，对 raw reads 做一步统一处理。它做的事情包括接头剪切、质量过滤、滑窗裁剪、长度过滤、polyG 剪切、可选的重叠纠错和去重，输出 clean reads 和一份 HTML/JSON 报告。它的优势在于 C++ 实现、速度比 Trimmomatic 快不少、单文件无复杂依赖、报告非常直观，而且支持双端数据的 overlap 分析来自动识别接头。

但它的边界也要清楚。Fastp 不做去宿主，宿主序列（比如粪便样本里的宿主 DNA）需要另外用比对工具去除，常见做法是 bowtie2 比对宿主参考基因组然后筛掉比上的 reads，这一步在 Fastp 之后做。Fastp 不做 rRNA 去除，宏基因组里 rRNA 占比可能高达 30% 以上，通常靠下游的 rRNA 预测工具或者专门的去除工具处理。Fastp 不做质量分布的可视化诊断，如果要做严格的批次质量评估，FastQC 那一套指标仍然值得看一眼，Fastp 的 HTML 报告只能覆盖一部分。

所以正确的心态是：Fastp 是流程里的第一道闸门，它负责把明显不合格的序列挡在外面，然后交给下游更精细的工具。把它当成"万能质控"是不现实的，把它当成"跑一下就行"的例行公事同样有问题。

2. Fastp 核心参数逐个拆，哪些该动哪些别动

2.1 质量过滤三件套：-q、-u、-e 的默认值与调整依据

Fastp 的质量过滤有三个相关参数，理解它们的分工是调参的前提。-q（qualified_quality_phred）定义"什么算合格碱基"，默认 15，也就是错误率大约 3.2%。-u（unqualified_percent_limit）定义"一条 read 里不合格碱基占多少比例就整条丢掉"，默认 40%。-e（average_qual）定义"一条 read 的平均质量低于多少就丢掉"，默认 0，也就是不启用。

这三个参数的关系是：先按-q给每个碱基打标签，再按-u判断整条 read 是否保留，-e是额外的一道平均质量闸门。默认值的设计思路是"宽松保留"，因为 Fastp 假设使用者会在下游再做严格过滤。

宏基因组场景下我一般会把-q提到 20，-u保持 40 或者降到 30。理由是这样：Q20 对应错误率 1%，这个阈值能挡掉大部分明显的测序错误，同时不会误伤质量值在 15 到 20 之间的大量"边缘碱基"。如果把-q提到 25 甚至 30，clean reads 的比例会明显下降，而且下降的部分往往集中在 GC 含量异常的物种上——宏基因组里 GC 偏好性本来就是偏差来源之一，再叠加质量过滤会进一步放大。

-e这个参数我通常不动，保持默认的 0。原因是平均质量是一个极不稳定的指标：一条 150 bp 的 read 如果前 100 bp 质量 Q35、后 50 bp 质量 Q10，平均下来可能还有 Q26，看起来挺合格，但后半段其实已经废了。平均质量的掩盖效应在小片段数据上尤其明显。与其用-e做粗筛，不如用滑窗裁剪把该切的切掉，剩下的自然就干净了。

提示：-q和-u是联动的。调高-q会让更多碱基被判为不合格，如果-u不变，就会有更多整条 read 被丢弃。这两个参数必须一起考虑，不能单独调一个。

2.2 滑窗裁剪：--cut_right 与 --cut_front/--cut_tail 的选择

滑窗裁剪是 Fastp 里对宏基因组影响最大的功能之一，但它默认是关闭的，必须显式开启。它有三个模式：--cut_front从 5' 端往 3' 端滑动，遇到平均质量低于阈值的窗口就切掉窗口内碱基；--cut_tail从 3' 端往 5' 端滑动，同理；--cut_right从 5' 端往 3' 端滑动，一旦遇到平均质量低于阈值的窗口，就把这个窗口以及它右边的全部碱基切掉。

窗口大小由--cut_window_size控制，默认 4；窗口平均质量阈值由--cut_mean_quality控制，默认 20。以默认值为例，一个 4 bp 的窗口平均质量低于 Q20，就触发裁剪。这个窗口大小不算大，4 bp 的窗口对单个异常碱基比较敏感，好处是能精准切掉质量陡降的区域，坏处是可能因为一两个碱基的随机波动就误切。

宏基因组我一般用--cut_front --cut_tail --cut_window_size 4 --cut_mean_quality 20，而不是--cut_right。原因是--cut_right是"一刀切"，从触发点往右全部丢弃，如果 read 中间出现一个偶然的低质量窗口，右半边即使质量很好也会被整段扔掉，这对低丰度物种的 reads 损失太大。--cut_front和--cut_tail只切窗口内的碱基，两边都扫一遍，保留中间质量好的部分，损失更可控。

参数值上，--cut_mean_quality 20是一个比较稳的平衡点。如果数据整体质量偏差（比如 Q30 比例低于 85%），可以考虑降到 15，先保住 reads 长度，把质量问题留给下游的比对算法处理；如果数据质量极好（Q30 高于 95%），提到 25 也无妨。但不建议超过 25，因为再往上就会开始伤及真实序列。

2.3 接头处理：自动检测的边界在哪里

Fastp 对双端数据的接头处理有两层机制。第一层是overlap 分析：双端 reads 如果来自同一个 DNA 片段，R1 和 R2 在 3' 端会有重叠区域，Fastp 通过比对这段重叠来推断接头序列并剪切。这个机制对插入片段短于两倍读长的文库特别有效。第二层是显式指定接头序列，用--adapter_sequence指定 R1 接头，--adapter_sequence_r2指定 R2 接头。

较新版本的 Fastp 对双端数据默认会做 overlap 分析，--detect_adapter_for_pe这个选项在某些版本里已经不需要显式开启。但我在实际使用中仍然倾向于显式加上--detect_adapter_for_pe，同时显式指定接头序列。显式指定的理由很实际：自动检测依赖 overlap 的质量，如果插入片段长度分布很宽、或者文库构建方式特殊，自动检测可能漏掉一部分接头；显式指定相当于给了一个确定的兜底。

Illumina TruSeq 系列的接头序列是固定的，R1 是AGATCGGAAGAGCACACGTCTGAACTCCAGTCA，R2 是AGATCGGAAGAGCGTCGTGTAGGGAAAGAGTGT。这两个序列我一般直接写死在脚本里。如果是其他建库试剂盒，接头序列要查对应说明书，不要照抄。

还有一个参数值得提：--overlap_len_require，默认 30。这个参数控制 overlap 分析要求的最小重叠长度。宏基因组文库插入片段通常在 300 到 500 bp，PE150 测序的重叠长度在 0 到 100 bp 之间浮动，默认值 30 是合理的。如果文库片段偏长（比如 600 bp 以上），重叠区域可能很短，这时候可以降到 20，但降太多会引入错误的 overlap 匹配。

2.4 长度、N 碱基与 polyG：三个不显眼但很关键的开关

长度过滤用-l（length_required）控制，默认 15。这个默认值非常宽松，几乎等于不过滤。宏基因组我一般设到 50，理由是：短于 50 bp 的 reads 在组装里基本不能形成有效 contig，在 k-mer 分类里也容易产生假阳性（k-mer 长度通常 21 到 35，50 bp 的 read 只能提供很少的 k-mer）。设到 50 以后，clean reads 数量会掉一点，但有效信息密度反而提升。

不过这里有个取舍要看下游。如果下游是组装（比如用 Megahit 或 SPAdes），-l 50合适；如果下游是物种分类（比如用 Kraken2），短 reads 虽然 k-mer 少但仍能贡献信号，可以放宽到 36；如果下游是功能注释比对，短 reads 的比对特异性差，还是保持 50 比较稳妥。我一般统一用 50，除非项目对 reads 数量有硬性要求。

N 碱基过滤用-n（n_base_limit）控制，默认 5。也就是一条 read 里 N 的数量超过 5 个就整条丢弃。这个默认值我基本不动。宏基因组里 N 的出现频率不高，5 个的上限已经足够宽松。如果发现大量 reads 因为 N 被丢弃，那说明测序质量本身有问题，调参数是治标不治本。

polyG 剪切用--trim_poly_g开启，--poly_g_min_len控制最小长度，默认 10。这个功能在检测到双色荧光测序平台（NextSeq、NovaSeq 系列）时会自动开启，但我在脚本里会显式写上，避免换平台或者换版本时行为不一致。polyG 是双色荧光系统的特有假象，单色系统（比如 MiSeq）不会产生，所以如果是 MiSeq 数据，这个参数开着也无害，因为找不到 polyG 就不会切。

另外还有一个--trim_poly_x，专门处理 PCR-free 建库产生的 polyX 假象（任意碱基的连续重复）。这个在宏基因组里用得少，除非明确知道文库是 PCR-free 构建的，否则不用开。

2.5 重叠纠错和去重：这两个功能我建议默认关闭

Fastp 有两个看起来很诱人但宏基因组要慎用的功能。

重叠纠错用--correction开启。它的原理是利用 R1 和 R2 的重叠区域，当同一位置两个 read 的碱基不一致时，用质量值更高的那个去纠正质量值更低的那个。听起来很合理，但宏基因组的特殊性在于：重叠区域的两个 read 来自同一个 DNA 片段，如果这个片段属于某个低丰度物种，纠错会改变它的碱基组成，进而影响后续的物种分类和分箱。更麻烦的是，这种改变是系统性的、和物种丰度相关的，高丰度物种的 reads 纠错后基本不变，低丰度物种的 reads 可能被改得面目全非。这会引入一种隐蔽的丰度偏差，事后很难察觉。

我的做法是默认关闭--correction。只有在数据质量确实很差（Q30 比例低于 85%）、而且下游只做物种分类不做定量分析时，才考虑开启，并且要在报告里注明。

去重用--dedup开启。它去掉的是完全相同的 read 对。宏基因组里真实的重复 reads 是丰度信号的一部分，高丰度物种本来就会产生大量相同序列的 reads，去重会直接削平这部分丰度。虽然 Fastp 的去重是基于完全匹配的，理论上只去掉 PCR 重复，但宏基因组的 PCR 循环数通常不高（十几轮），真正的 PCR 重复占比有限，去重带来的丰度失真反而更值得担心。

所以这两个功能我的默认配置都是关闭。如果项目方明确要求去重（比如做绝对定量），那要在流程文档里写清楚，并且下游分析时要意识到丰度已经被改变过。

3. 一套能直接跑的宏基因组质控命令

3.1 单样本命令逐行注释

下面这条命令是我目前宏基因组项目里的基础版，参数按上一章的逻辑设定，可以直接复制改路径使用。

fastp \ -i sample_R1.fastq.gz \ -I sample_R2.fastq.gz \ -o sample_clean_R1.fastq.gz \ -O sample_clean_R2.fastq.gz \ --detect_adapter_for_pe \ --adapter_sequence AGATCGGAAGAGCACACGTCTGAACTCCAGTCA \ --adapter_sequence_r2 AGATCGGAAGAGCGTCGTGTAGGGAAAGAGTGT \ --cut_front \ --cut_tail \ --cut_window_size 4 \ --cut_mean_quality 20 \ -q 20 \ -u 40 \ -n 5 \ -l 50 \ --trim_poly_g \ --poly_g_min_len 10 \ -w 12 \ --json sample.fastp.json \ --html sample.fastp.html \ -R "sample_qc_report" \ 2> sample.fastp.log

逐段解释一下关键选择。--detect_adapter_for_pe加上显式接头序列是双保险，前者靠 overlap 检测，后者靠序列匹配，两条路都走一遍，接头残留概率最低。--cut_front --cut_tail双向滑窗，比--cut_right温和，保留更多有效序列。-q 20 -u 40是前面说的平衡点。-l 50是宏基因组的实用下限。--trim_poly_g显式写出来保证跨平台一致性。-w 12是线程数，一般设成物理核心数的 60% 到 80%，留出 IO 和其他进程的空间。-R给报告加标题，批量跑的时候方便在 HTML 里区分样本。2>把日志单独存，Fastp 的 stderr 里有关键的统计信息，出错时是排查的第一手材料。

关于线程数，还有一个实操细节：-w设太大并不会一直更快。Fastp 的主要瓶颈在 gzip 解压和写盘，线程数超过 16 以后收益递减明显，反而可能因为 IO 争抢导致整体变慢。我在 32 核的机器上实测，-w 12和-w 24的耗时差距不到 10%，但内存占用和 IO 压力差别明显。

3.2 批量样本的调度脚本

宏基因组项目动辄几十个样本，手工跑不现实。我一般用一个简单的 shell 循环加并发控制，不依赖任何流程管理框架，好处是透明、好排查。

#!/bin/bash set -euo pipefail RAW_DIR="./raw" CLEAN_DIR="./clean" REPORT_DIR="./qc_report" THREADS=12 PARALLEL=4 mkdir -p "${CLEAN_DIR}" "${REPORT_DIR}" run_one() { local sample="$1" fastp \ -i "${RAW_DIR}/${sample}_R1.fastq.gz" \ -I "${RAW_DIR}/${sample}_R2.fastq.gz" \ -o "${CLEAN_DIR}/${sample}_clean_R1.fastq.gz" \ -O "${CLEAN_DIR}/${sample}_clean_R2.fastq.gz" \ --detect_adapter_for_pe \ --adapter_sequence AGATCGGAAGAGCACACGTCTGAACTCCAGTCA \ --adapter_sequence_r2 AGATCGGAAGAGCGTCGTGTAGGGAAAGAGTGT \ --cut_front --cut_tail \ --cut_window_size 4 --cut_mean_quality 20 \ -q 20 -u 40 -n 5 -l 50 \ --trim_poly_g --poly_g_min_len 10 \ -w "${THREADS}" \ --json "${REPORT_DIR}/${sample}.fastp.json" \ --html "${REPORT_DIR}/${sample}.fastp.html" \ -R "${sample}" \ 2> "${REPORT_DIR}/${sample}.fastp.log" } export -f run_one export RAW_DIR CLEAN_DIR REPORT_DIR THREADS ls "${RAW_DIR}"/*_R1.fastq.gz \ | sed 's#.*/##; s/_R1.fastq.gz//' \ | xargs -I{} -P "${PARALLEL}" bash -c 'run_one "$@"' _ {}

这段脚本的核心是xargs -P做并发控制。PARALLEL=4配合THREADS=12，总线程占用约 48，适合 64 核左右的机器。如果你的机器核数少，把PARALLEL降到 2，THREADS提到 8，总占用控制在核数的 80% 以内。

注意：并发数和单任务线程数的乘积不要超过物理核心数太多。超了以后多个 Fastp 进程会互相抢 IO，总耗时反而变长，而且 gzip 写入可能因为缓冲不足出现异常。

脚本里用set -euo pipefail是刻意的。宏基因组批量跑最怕的是某个样本静默失败，等你发现的时候已经跑完了全部样本，还得回头找哪个出了问题。加上这个设置，任何一个样本出错脚本立即停止，日志里能直接定位。

3.3 报告怎么读：三个必须看的指标

Fastp 的 HTML 报告信息量很大，但宏基因组真正要盯的只有几个指标。

第一是 clean reads 比例，报告里的 "After filtering" 部分。一般来说，宏基因组数据这个比例在 90% 以上算正常，85% 到 90% 需要看一眼原因，低于 85% 就要深入排查了。比例低常见的原因有三个：原始数据质量差、接头含量高、或者-l 50切掉了太多短片段。要区分这三种情况，看报告里 "Filtering result" 的细分：因为 too short 丢了多少、因为 too many N 丢了多少、因为 low quality 丢了多少。如果 too short 占大头，说明文库片段偏短，可以考虑把-l降到 36；如果 low quality 占大头，说明测序质量本身有问题。

第二是 Q20 和 Q30 比例，报告里的 "Qualities" 部分。质控后的 Q30 比例建议在 90% 以上，Q20 在 95% 以上。如果质控后 Q30 还不到 85%，说明滑窗裁剪的力度不够或者原始数据质量太差。这时候不要急着调参数，先看质量分布图：如果质量下滑集中在 3' 端末尾几十 bp，加大--cut_tail的力度有效；如果整条 read 质量都偏低，那是测序问题，调参无用。

第三是插入片段长度分布，报告里的 "Insert size estimation" 部分。这个图能反映文库构建质量。正常的宏基因组文库应该是一个以 300 到 500 bp 为中心的宽峰。如果峰值出现在很短的区域（比如 100 bp 以下），说明存在大量引物二聚体或者文库片段化过度。如果分布异常宽或者出现双峰，可能是建库时片段筛选没做好。这个信息对判断数据可用性非常关键，但很多人看报告时直接跳过。

3.4 质控之后接去宿主：顺序与衔接细节

Fastp 跑完之后，宏基因组流程的下一步通常是去宿主。顺序上一定要先质控再去宿主，理由是：接头和低质量碱基会干扰比对，带着接头去比对宿主参考基因组，会产生大量假比对和软剪切，去宿主的结果就不可信了。而且去宿主用的比对工具（比如 bowtie2）对 reads 长度有隐含要求，太短的 reads 比对特异性差，会误删真实微生物序列。

去宿主的典型命令是这样：

bowtie2 -p 12 -x host_ref \ -1 sample_clean_R1.fastq.gz \ -2 sample_clean_R2.fastq.gz \ --un-conc-gz sample_host_removed_%.fastq.gz \ 2> bowtie2.log | \ samtools view -bS - | \ samtools sort -@ 4 -o sample_host_aligned.bam

--un-conc-gz输出的是没有比对到宿主的 read 对，这个才是下游要用的。%.fastq.gz里的%会被替换成1和2，分别对应 R1 和 R2。比对上的部分存成 BAM 备查，万一发现去宿主去过头了，还能回溯。

这里有个细节要留意：bowtie2 对短于 50 bp 的 reads 默认会关闭部分比对模式，这也是前面把-l设到 50 的一个连带考虑。如果质控时把长度下限设成 36，去宿主阶段可能有一部分 reads 被 bowtie2 直接跳过，导致结果不一致。

去宿主之后的 reads 数量通常还会再掉 1% 到 10%，具体取决于样本类型。粪便样本宿主占比低，掉得少；组织样本或者血液样本宿主占比高，可能掉 50% 以上。这个比例要在项目记录里写清楚，因为下游做丰度归一化时，"总 reads 数"到底是指质控前、质控后还是去宿主后，不同定义会得出完全不同的结论。

4. 踩坑实录：那些参数跑完才发现的问题

4.1 数据量掉得离谱，问题往往不在参数

有一批样本，质控后 clean reads 只剩下原始的 62%，而同一批次的另外几个样本都在 92% 以上。第一反应是参数问题，逐个排查后发现参数完全一样。于是去看--failed_out输出（我没在基础命令里加这个参数，排查时临时加上去的），把被丢弃的 reads 导出来看，发现全是富含 AT 的短序列，长度集中在 30 到 45 bp 之间。

这批数据的实际情况是：建库时片段筛选没做好，产生了大量短片段，这些短片段在 PE150 测序里读穿了整个插入片段，后半段全是接头。Fastp 的接头剪切把接头切掉之后，剩下的有效序列自然就短了，-l 50一卡，整条丢掉。这不是参数错，是数据本身的特征。处理办法是把-l降到 36，同时在下游组装时把最小 contig 长度从 500 提到 800，用更严格的组装过滤来补偿短 reads 带来的噪音。

这个坑的教训是：clean reads 比例异常时，先看被丢弃的 reads 长什么样，再决定调不调参数。--failed_out这个参数平时不用加，排查时加上，能省掉大量猜测时间。用法是--failed_out failed.fq.gz，输出的是所有被过滤掉的 reads，可以拿去 FastQC 或者直接 zcat 看几条。

4.2 接头残留与 overlap 误判的辨别方法

接头残留的典型症状是：质控报告显示接头已经剪切，但下游比对时 soft-clip 比例异常高，或者组装出来的 contig 末端出现非生物学的重复序列。判断方法很直接，用 grep 在 clean reads 里搜接头核心序列：

zcat sample_clean_R1.fastq.gz | head -400000 | grep -c "AGATCGGAAGAGC"

如果 40 万条 reads 里能搜到几百条以上，说明接头剪切不彻底。原因可能是 overlap 分析失败（插入片段太长，R1 和 R2 没有重叠），或者接头序列和显式指定不一致（用了非 TruSeq 的试剂盒）。解决办法是查清试剂盒的接头序列，显式指定；如果插入片段确实很长，考虑用专门的接头剪切工具做二次处理。

overlap 误判是另一个隐蔽问题。表现是 clean reads 长度分布出现异常的双峰，一部分 reads 被切得特别短。原因是 Fastp 在 overlap 分析时，如果两条 reads 的 3' 端偶然出现匹配，可能误判为接头并剪切。这种情况在低复杂度序列（比如 polyA 尾）上特别容易发生。缓解办法是提高--overlap_len_require，从默认 30 提到 35 或 40，减少偶然匹配的概率。代价是短插入片段的接头可能漏切，需要权衡。

4.3 速度、线程与内存的实测数据

我在一台 64 核、256 GB 内存的机器上做过一组对比测试，样本是 6 GB 的 PE150 宏基因组数据，gzip 压缩。

从数据看，单样本线程数超过 12 以后收益很小，瓶颈在 IO。但如果并行跑多个样本，总吞吐会明显提升，因为多个进程可以错开 IO 等待。所以批量场景下"少线程多并行"比"多线程单并行"更划算。

内存方面，Fastp 的内存占用主要和线程数、reads 长度相关，单样本通常不超过 3 GB。但要注意 gzip 输出的缓冲，如果输出目录所在磁盘 IO 慢，缓冲区会堆积，内存占用会比预期高。我曾经遇到过一次内存告警，排查发现是输出目录挂载在网络存储上，写入延迟导致缓冲堆积，换成本地盘后恢复正常。

4.4 常见问题速查表

这张表里的每一条我都至少遇到过一次，其中"下游物种多样性异常低"这一条最容易被误判。因为它不报错，流程照常跑完，只有在做多样性分析时才发现 alpha 多样性比预期低很多。排查方法是拿同一批数据用两套参数各跑一遍，对比物种注释结果，差异集中在低丰度物种上，基本就能确认是质控过严。

5. 工程化收尾：让质控这一步不再成为返工点

5.1 批次间参数一致性比参数本身更重要

做宏基因组项目，最忌讳的是"这批数据看起来质量差一点，我调一下参数"。因为一旦参数不一致，后面所有的比较分析都失去了基础。你今天用-q 20 -l 50跑了十个样本，明天觉得另外五个样本质量差，改成-q 15 -l 36，看起来是"因材施教"，实际上引入了一个无法量化的批次效应：不同样本的 reads 被过滤的标准不一样，物种丰度的相对关系已经被改变了。

我的做法是项目启动时定一套参数，整个项目不改。如果确实遇到某个样本质量特别差，处理方式是：要么整批重跑，要么把这个样本标记为异常并在分析时单独说明，绝不单独调参。参数的选择依据可以写在项目文档里，比如"基于预实验数据的 Q30 分布，选择-q 20"，这样即使别人接手也能理解为什么这么选。

还有一个细节是参数要跟着脚本走，不能跟着人走。我见过实验室里每个人都有自己的 fastp 命令，跑出来的结果互相对不上。解决办法是把命令封装成脚本，脚本进版本管理，每次运行记录脚本版本号。这样半年后回头看某批数据，能准确知道当时用的什么参数。

5.2 版本锁定与目录规范

Fastp 的版本更新会带来行为变化，最典型的是默认参数调整和自动检测逻辑的改动。比如某些版本对双端数据默认开启 overlap 分析，某些版本对 polyG 的自动检测条件有变化。如果不在环境里锁定版本，半年后重跑同一批数据可能得到不一样的结果。

我的做法是用 conda 环境锁定版本，环境文件里写死 fastp 的具体版本号，整个项目周期不升级。同时在项目目录下留一份env_export.yml，记录完整的依赖树。这样即使原始环境损坏，也能精确重建。

目录结构上，我习惯把质控环节的输出单独放一层，和原始数据、去宿主结果、组装结果平级：

project/ ├── 00_raw/ ├── 01_qc/ │ ├── clean/ │ ├── report/ │ └── log/ ├── 02_host_removed/ ├── 03_assembly/ └── ...

这样做的实际好处是：排查问题时能快速定位到某一层，重跑时只需要删掉对应目录，不会误删其他环节的结果。报告和日志分开存也是刻意的，报告给人看，日志给脚本和排查用，混在一起时间长了会很乱。

5.3 下游衔接前的最后检查清单

质控跑完之后，别急着往下走。我一般会做一个几分钟的检查，能挡掉大部分后面才会暴露的问题。

第一，看 clean reads 数量是否满足下游最低要求。组装一般要求每个样本至少 3 Gb 有效数据，物种分类要求低一些，1 Gb 也能跑但低丰度物种检出率会下降。如果某个样本 clean 后不到 1 Gb，要提前和项目方沟通，别等组装跑完才发现数据不够。

第二，随机抽几条 clean reads 肉眼看一下。听起来很原始，但很有效。zcat clean_R1.fastq.gz | head -8看前两条 read 的序列和质量值，如果开头就是一堆低质量字符，说明滑窗裁剪没生效；如果序列末尾还有明显的接头特征，说明接头剪切有问题。这个动作花不了一分钟，但能发现很多自动化检查漏掉的问题。

第三，对比质控前后的 reads 数量比例是否符合预期。同一个项目里，各样本的 clean ratio 应该大致接近，如果某个样本明显偏离，要么是数据本身异常，要么是样本类型不同（比如宿主占比差异大）。这个偏离本身不是错误，但要在分析时作为协变量考虑。

第四，确认报告文件和日志文件都完整生成。Fastp 偶尔会因为磁盘满或者权限问题导致报告写入失败但主流程不报错，等到要汇总报告时才发现缺了几个样本。用一个简单的ls report/*.html | wc -l和样本数对比一下，十几秒的事。

我个人在实际操作中的体会是，宏基因组质控这一步的技术门槛不高，难的是保持一致性和可追溯性。参数怎么设，看几篇文档就能定；但能不能在几十个样本、几个月周期、多个人协作的情况下始终用同一套标准，并且随时能说清楚每个样本经历了什么处理，这才是真正拉开差距的地方。Fastp 这条命令本身十分钟就能学会，把它用稳、用出可复现的结果，需要的是流程意识而不是工具技巧。