企业官网建设流程全解析

做生信的朋友，对 Trimmomatic 这个名字应该都熟。它是二代测序数据预处理阶段最常被提到的工具之一，专门处理下机后最原始的 FASTQ 文件：去接头、剪低质量碱基、过滤掉太短的序列。如果说测序是原料采购，那 Trimmomatic 就是洗菜、切菜和挑烂叶子的环节，后面不管是比对、组装还是定量，吃进去的都是这份处理后的干净数据。这篇内容主要适合刚接触生信、准备跑 RNA-seq 或全基因组流程、以及想自己搭一套分析 pipeline 的人，我会把 PE 双端模式的核心逻辑、每个参数背后的设计动机，还有我实际使用中踩过的坑都拆开讲清楚。

1. 先看明白：Trimmomatic 到底在清理什么

1.1 FASTQ 里的“脏东西”主要有三类

测序仪下机后的数据远没有想象中干净。第一类是接头残留，建库时那段用于捕获和扩增的已知序列，有时会被一起读出来，直接留在 read 的末端或中间；第二类是低质量碱基，测序越往后面信号衰减越明显，read 3' 端的碱基质量往往越来越差；第三类是长度不合格的序列，比如整条 read 被修剪得太短，已经没有比对或组装价值。如果不做处理，下游比对时会出现大量横跨外显子或不匹配的 read，组装时则会贡献一堆虚假的 contig。

Trimmomatic 的定位就是针对这些问题做“定点清除”。它不是像 FastQC 那样只输出质量报告，而是真正动手改造数据，输出修剪后的新 FASTQ 文件。FastQC 负责诊断，Trimmomatic 负责治疗，两者配合使用是标准的质控流程。

1.2 Phred 质量值的读取方式：为什么有时候会看到“乱码”

要理解 Trimmomatic 的参数，先得懂 FASTQ 文件里质量值是怎么编码的。FASTQ 的第四行是一串 ASCII 符号，每个符号对应一个质量分数。常见的编码体系是 Phred+33，也就是 ASCII 码值减去 33 得到 Q 值；另一个是 Phred+64，对应老版本 Solexa 或部分旧平台数据，码值减去 64 得到 Q 值。

Q 值的计算公式是 Q = -10 * log10(P)，其中 P 是碱基判读错误的概率。Q20 代表错误率 1%，Q30 代表错误率 0.1%。如果直接用文本编辑器打开 FASTQ 文件，看到的第四行是一堆看起来像乱码的符号——IIIIIIIIIIIIIIIIIII这种就是质量很高的表现。老版本 Trimmomatic 需要手动指定-phred33或-phred64，新版本会自动识别，但如果你在用某个旧版本开源镜像里的脚本，还是容易踩到这个坑。判断数据是哪套编码体系，看 FastQC 输出的质量分布图最直接，也可以观察 ASCII 符号范围：如果在 33 到 74 之间，基本是 Phred+33；如果大量出现小于 59 的符号却显示高质量，可能就是 Phred+64。

1.3 跳过预处理的代价

很多人嫌预处理麻烦，尤其是手头数据已经经过了某平台的官方质控，觉得可以跳过。我见过不止一次直接拿原始 FASTQ 去做比对，结果 mapping rate 从 85% 掉到 60% 多的情况。接头残留会导致 read 的末端全部比对到同一段已知序列上，产生大量不可信的比对；低质量碱基则会让错配增多，尤其在 SNP 检测中，这些位置很容易被误判成变异位点。做一次 Trimmomatic 通常只需要几分钟到十几分钟，省下的却是下游排查问题的数小时时间。

2. PE 双端模式：理解四个输出文件背后的逻辑

2.1 PE 模式为什么会产生 paired 和 unpaired 两种输出

Trimmomatic 最常用的场景是双端测序，即一对 read 分别来自 DNA 片段的两端，用 PE 模式处理时，命令会指定两个输入文件和四个输出文件。这四个文件分别对应 R1 端保留且 R2 端也保留的 paired 数据，以及只有一端能保留、另一端因为太短被丢弃的 unpaired 数据。

刚接触的人经常不理解为什么还要输出 unpaired reads。我的理解是：Trimmomatic 的设计理念是“能救就救”。假设 R1 端质量很好，长度也够，但 R2 端因为测序深度不够或质量太差被修剪到了 MINLEN 以下，这时候如果强制把成对的 R1 也丢掉，就白白浪费了一部分可用数据。某些下游工具，比如组装类的 SPAdes，是支持单独使用 unpaired reads 的；即使在比对流程中，如果某一步骤只接受 paired 文件，这些 unpaired reads 也可以在后续步骤作为单端数据补充进去。

2.2 四个输出文件在实际流程中的去向

实际写 pipeline 的时候，我会把 PE 配对文件作为主分析输入，而把两个 unpaired 文件攒起来，留到需要单端数据的环节再用。比如跑某个基因组组装项目时，SPAdes 命令里可以直接指定--unpaired参数，把这些原本会被丢弃的数据重新派上用场。RNA-seq 定量流程中，如果比对工具支持单端模式，也可以把这些 reads 单独比对后再合并统计。

有一点要特别说明：如果一条 read 因为接头残留被剪掉了一大段，但另一端完全正常，那么被剪短的一端如果还能达到 MINLEN，它仍然会进入 paired 输出，只是长度变短了。Trimmomatic 的判断逻辑是看修剪后是否满足最小长度，而不是看是否发生了修剪。

2.3 单端 SE 模式只需要两个文件

SE 模式相对简单，输入一个 FASTQ 文件，输出一个修剪后的 FASTQ 文件。SE 模式下无法使用依赖双端信息的 palindrome 接头检测，只能依赖 simple 模式。如果你的数据本身是单端测序，或者少数 read 被单独保存为单端文件，就用 SE 模式跑。

3. 核心参数逐条拆解：明白每一步在干什么

3.1 ILLUMINACLIP：接头去除的两种检测机制

ILLUMINACLIP 是 Trimmomatic 最复杂的参数，格式为ILLUMINACLIP:adapters.fa:seedMismatches:palindromeClipThreshold:simpleClipThreshold。我这里用一个实际例子来说明：ILLUMINACLIP:TruSeq3-PE.fa:2:30:10。

第一个值是允许的种子序列错配数，常用 2，偶尔调整到 1 会更严格；第二个值是 palindrome 模式下的剪接得分阈值，通常 30 到 40；第三个值是 simple 模式下的阈值，一般设 10 到 12。注意adapters.fa里必须放你实际建库用的接头序列，Trimmomatic 安装包自带的 TruSeq、Nextera 等文件只是常见平台的默认接头集合。

palindrome 模式是双端数据的特有优势。当双端 reads 是从同一个 DNA 片段两端测序且片段较短时，两条 reads 会在中间区域相互重叠，形成一条长序列，此时接头序列往往会出现在重叠区域的末端。Trimmomatic 会把 R1 和 R2 拼成一条序列来检测接头，这样即使接头本身有测序错误，也能通过整体评分识别出来。simple 模式则是每条 read 独立找接头，适合检测那些没有形成重叠、直接读到接头的 read。两个阈值越高，剪接越保守，误剪风险越低，但也越容易漏掉真实接头。

3.2 LEADING 和 TRAILING：读首读尾的定点修剪

LEADING:3的意思是如果 read 5' 端某个碱基质量值低于 3，就持续向前切除，直到遇到一个质量达标的碱基为止。TRAILING 的逻辑完全相同，只是从 3' 端往回收。这个参数阈值设得很低（比如 3 或 5），因为 5' 端和 3' 端的末尾偶尔会出现一两个质量极低的碱基，但又不值得因此动用滑窗把整条 read 切掉一大段。LEADING 和 TRAILING 是“点状清理”，动作轻，成本低。

在实际数据里，5' 端低质量很少出现，3' 端低质量则很常见，所以 TRAILING 通常比 LEADING 影响更大。如果你发现样本的 3' 端质量整体衰退严重，可以把 TRAILING 提高到 5 甚至 10，这会切掉更多低质量尾部碱基，但同时也会让 read 变短。这个取舍要看你的下游分析需求。

3.3 SLIDINGWINDOW：为什么用窗口平均质量而不是单碱基质量

SLIDINGWINDOW 是 Trimmomatic 最核心的质量过滤步骤。格式是SLIDINGWINDOW:windowSize:requiredQuality，最经典的参数是SLIDINGWINDOW:4:15，意思是每次取 4 个碱基作为一个窗口，计算窗口内碱基的平均质量，如果平均质量低于 15，就从窗口的第一个碱基位置开始往右全部切除，然后窗口向后移动一个碱基，继续判断剩余序列是否符合要求。

为什么不用单碱基质量直接判断？因为测序仪每个碱基的质量分数本身有一定噪声，单看一个碱基很容易因为个别波动做出错误判断。取 4 个碱基平均能滤掉这种随机波动，同时保留对整体质量趋势的敏感度。窗口大小选 4 而不是 10，是因为窗口太大会导致质量信号被稀释，某些已经明显变差的区域可能因为混入几个高质量碱基而“蒙混过关”；窗口太小又容易过度修剪。4:15 是经过大量实践验证的经验值，大多数常规转录组、基因组数据用这个参数都不会出错。

3.4 MINLEN：长度过滤的底线思维

MINLEN:36的意思是经过所有修剪步骤后，如果 read 长度还不足 36 个碱基，就整条丢弃。这个值的核心逻辑是：太短的 read 很难定位到参考基因组上的唯一位置，还容易造成多比对或错误比对，宁可丢掉也不留给下游添乱。

MINLEN 的取值要结合实际场景：如果是 150 bp 的 PE 数据，建议 36 或 50；如果后续做转录组定量，比对算法对短 read 的容忍度更低，可以适当提高。如果设得太高，比如 100，会把很多质量不错但被 TRAILING 削掉一段的 read 也丢掉，导致整体数据量锐减；设得太低，比如 20，下游比对工具会报错或产生大量低质量比对。做组装时，SPAdes 对短 read 的容忍度相对高一些，可以适当放低 MINLEN，但也不建议低于 30。

3.5 参数顺序会影响结果

Trimmomatic 是严格按照命令行顺序执行各步骤的。一般推荐的顺序是：先 ILLUMINACLIP 去接头，再 LEADING、TRAILING 修两端，接着 SLIDINGWINDOW 扫内部质量，最后 MINLEN 做长度筛选。先去掉接头、再处理质量，可以避免接头序列上的碱基干扰质量判断；而如果先做质量修剪再接下去接头，修剪过程可能已把接头序列切掉一部分，导致残留接头检测不出来。实际调整参数时，我会先跑一遍默认参数看日志，再根据结果微调顺序和阈值。

4. 实操全流程：从原始 FASTQ 到干净数据

4.1 环境准备：Java 和 jar 包

Trimmomatic 是 Java 写的，所以机器上需要有 Java 运行环境。一般 OpenJDK 8 或 11 都够用，不用特意装最新版。去官网下载对应版本的 jar 包，放到一个专门的软件目录，比如~/tools/Trimmomatic-0.39/。每次运行时用java -jar调用即可。

我把 Trimmomatic 单独放在一个目录，同时把适配文件也在同目录下放着，因为 ILLUMINACLIP 参数里的 adapters 文件路径建议用绝对路径或相对路径写清楚，避免脚本在不同工作目录下运行时找不到文件。

4.2 一条实际可用的 PE 命令

假设有一对样本文件sample_R1.fastq.gz和sample_R2.fastq.gz，都位于同一目录下，命令可以这样写：

java -jar ~/tools/Trimmomatic-0.39/trimmomatic.jar PE \ -threads 8 \ sample_R1.fastq.gz sample_R2.fastq.gz \ output_R1_paired.fq.gz output_R1_unpaired.fq.gz \ output_R2_paired.fq.gz output_R2_unpaired.fq.gz \ ILLUMINACLIP:~/tools/Trimmomatic-0.39/adapters/TruSeq3-PE.fa:2:30:10 \ LEADING:3 \ TRAILING:3 \ SLIDINGWINDOW:4:15 \ MINLEN:36

注意看几个关键位置：PE 之后的-threads 8是设定并行线程数，通常设成 CPU 核数的一半或略多即可；四个输出文件的顺序必须严格对应 R1 paired、R1 unpaired、R2 paired、R2 unpaired，很多人第一次用就在这里写反了；输入文件如果是 gzip 压缩格式，Trimmomatic 会根据文件名后缀自动解压和再压缩，所以直接用.fastq.gz没问题。

有的流程里会把未配对的 R1 和 R2 unpaired 合并成一个文件，便于后续作为单端输入，但我更建议单独保留，因为不同来源的 unpaired 数据质量特征可能不同，混合后不好追踪。

4.3 如何看懂 Trimmomatic 的日志输出

运行结束后，屏幕上会打印一串摘要信息，比如：

Input Read Pairs: 1000000 Both Surviving: 850000 (85.00%) Forward Only Surviving: 50000 (5.00%) Reverse Only Surviving: 30000 (3.00%) Dropped: 70000 (7.00%)

这四行数据很重要。Both Surviving是双端都保留下来的比例，是后续分析的主体；Forward Only和Reverse Only是进入 unpaired 文件的 reads 比例；Dropped是彻底丢弃的比例。理想情况下，Both Surviving 应该在 80% 以上。如果 Dropped 比例超过 20%，我会先去 FastQC 里看具体是什么问题，而不是盲目调参数。

日志还带有每个步骤处理前后 reads 数，比如 ILLUMINACLIP 识别出多少条含有接头的 reads、SLIDINGWINDOW 从头修剪了多少条，这些信息对判断数据质量非常有用。

4.4 脚本化批量处理

手头样本多的时候，我不会手动一条条敲命令，而是写一个简单的 Shell 循环。示例逻辑如下：

for sample in $(cat sample_list.txt); do java -jar ~/tools/Trimmomatic-0.39/trimmomatic.jar PE \ -threads 8 \ ${sample}_R1.fastq.gz ${sample}_R2.fastq.gz \ ${sample}_R1_paired.fq.gz ${sample}_R1_unpaired.fq.gz \ ${sample}_R2_paired.fq.gz ${sample}_R2_unpaired.fq.gz \ ILLUMINACLIP:~/tools/Trimmomatic-0.39/adapters/TruSeq3-PE.fa:2:30:10 \ LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36 done

建议在循环里加入日志重定向，以便后续核验每个样本的存活率：

... > ${sample}_trimmomatic.log 2>&1

批处理完后，用一行命令快速提取所有样本的Both Surviving比例，就能定位质量异常的样本。

4.5 与 FastQC 和下游流程的衔接

标准流程建议是：先对原始 FASTQ 跑一次 FastQC，拿到质量分布、GC 含量、接头残留等信息，心里有数后再跑 Trimmomatic。修剪完成后再跑一次 FastQC，确认接头残留是否消除、质量分布是否改善。这两次对比能直观反映预处理效果。

下游流程中，比对工具如主流比对软件接受 paired 和 unpaired 文件，但命令写法不同；组装工具可以同时接受 paired 和 unpaired。通常在 workflow 里，我会把*_paired.fq.gz作为主输入，unpaired 文件单独存档，等组装阶段再看是否需要。

5. 常见问题与排查：我踩过的一些实际坑

5.1 大量 reads 被丢弃，Dropped 比例异常高

如果 Both Surviving 降到了 50% 以下，第一件事是打开日志，看 MINLEN 前后的 reads 数变化。如果大量 reads 都栽在 MINLEN 这一关，说明原本 read 长度就不够，或者 SLIDINGWINDOW 修剪太狠。这时我会去看 FastQC 的 per-base sequence quality 和 sequence length distribution，确认是测序本身质量问题还是参数问题。

一个常见情况是：样本测序深度不够，有效长度本身就参差不齐。这时可以尝试把 MINLEN 降低到 30，同时把 SLIDINGWINDOW 的阈值从 15 降到 12，看是否能保住更多 reads。但降低阈值是有代价的，保留下来的 reads 质量会略差，需要在数据量和数据质量之间找到平衡。

5.2 接头残留没去掉，日志显示 ILLUMINACLIP 只处理了不到 1% 的 reads

接头没有去除干净，最可能的原因是适配器文件里没有包含你实际使用的接头序列。不同建库试剂盒用的接头不同，如果 Trimmomatic 自带的 TruSeq3-PE.fa 和你手头的文库不匹配，自然检测不到。比如某次我用自带文件处理某定制接头时，日志中接头识别率几乎为 0，但 FastQC 的 overrepresented sequences 里却明显有接头信号。

解决方法是先跑 FastQC，查看 overrepresented sequences 的具体序列内容，再对照自带的 adapters 文件，或者从试剂盒说明书里找到正确的接头序列，写入自定义的my_adapters.fa文件，然后替换 ILLUMINACLIP 参数里的文件路径。另外，如果用的是双端数据但接头没有形成重叠，palindrome 检测不到，可以适当降低 simple 模式的阈值到 8 左右，提高灵敏度，但要注意降低阈值可能带来误剪。

5.3 报错信息与内存问题

运行过程中最常见的报错是 Java 堆内存不足，提示java.lang.OutOfMemoryError。Trimmomatic 读取大 FASTQ 文件时，默认 JVM 分配的内存可能不够，尤其是几百 GB 的全基因组数据。这时在java -jar前加-Xmx4g或-Xmx8g，例如：

java -Xmx8g -jar ~/tools/Trimmomatic-0.39/trimmomatic.jar PE ...

-Xmx8g表示最大堆内存 8 GB，可以根据服务器可用内存调整，一般 4 GB 足够处理大多数单样本数据，全基因组级别的建议 8 GB 以上。

另一个容易遇到的报错是输入文件格式问题。如果 FASTQ 文件被其他工具处理过，行数不统一或者质量编码不一致，Trimmomatic 会报出解析错误。解决办法是先检查文件完整性，或重新下载原始数据，不要强行修文件，否则结果不可靠。

5.4 输出文件里空文件

如果某个样本输出文件为空，先看是不是输入文件本身就是空文件，或者文件是否被压缩格式搞混。比如有人把.fq.gz的文件改名为.fq，Trimmomatic 按未压缩文件读取，就会解析失败。这种情况用file命令检查实际格式最直接。

还有一个小坑是输出目录与输入目录相同，且文件名前缀一致，可能覆盖掉原始文件。我习惯把原始 FASTQ 单独放一个raw_data目录，修剪后的输出放另一个cleaned_data目录，避免不小心覆盖原数据。

5.5 单端模式下的常见注意事项

SE 模式下无法使用 palindrome 检测，所以接头去除只能靠 simple 模式，这会让接头检测灵敏度下降。如果你处理单端数据时遇到接头残留，除了降低 simple 阈值，还可以先用 FastQC 明确接头序列，手动补充到 adapters 文件中。SE 模式输出的文件只有修剪后的单端文件，没有 paired 和 unpaired 之分，所以日志中的处理结果描述也会相应简化。

6. 参数调整的几个实战建议

6.1 用默认参数优先，再用数据和经验微调

对于绝大多数标准建库数据，LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36这套参数是经过大量文献和生产流程验证的基准。我不建议一上来就大改特改，而是先按默认参数跑一遍，再看日志和 FastQC 前后对比，有的放矢地微调。比如 RNA-seq 数据如果平均 read 长度偏短，可以把 MINLEN 降一点；某个样本质量波动大，可以把 SLIDINGWINDOW 改成4:12提高保留率。

6.2 不同数据类型适合的参数组合参考

这张表只是经验的起点，不是标准答案。真正的参数取舍永远要结合 FastQC 报告和下游流程需求来定。

6.3 保存配置文件，保证可复现

项目里我会把所用 Trimmomatic 版本、jar 包路径、参数行记录在一个params.txt里，每次跑完批处理就把日志文件汇总归档。保存这些元信息对后续排查和论文方法部分写作都很有价值。以前吃过亏：某次临时改了一个参数忘了记录，后来想复现当时的结果，费了好大劲才从日志里反推出来。

7. 我自己的使用体会

用 Trimmomatic 时间越长，越觉得它的设计贴合实际需求：双端模式考虑到了“能救就救”的单端保留策略，参数顺序设计让每一步操作都有明确作用，日志输出又足够直观，方便快速判断数据质量。我最深的体会是，预处理这一步看似机械，但恰恰是决定整个分析流程成败的底层环节——很多下游分析结果异常，追根溯源都能回到原始数据没洗干净。所以每次拿到新数据，我都愿意花十几分钟先跑一遍 FastQC 和 Trimmomatic，把数据脾性摸清楚，再决定后续怎么走。刚开始做生信的朋友，与其纠结各种高级分析工具，不如先把 Trimmomatic 配合 FastQC 这套基本功练扎实，后面会少走很多弯路。