Trimmomatic 这东西，做二代测序数据分析的人大概率都用过或者迟早会用上。刚拿到手的原始下机数据（fastq）远没有想象中那么清爽，接头残留、末端低质量碱基、异常短片段，这些垃圾不清理掉，后续比对和组装轻则浪费算力,重则直接产出假结果。Trimmomatic 就是干这个的核心工具：把低质量碱基剪掉、把接头序列剪掉、把太短的读长过滤掉，一步到位，而且是 Java 写的，跨平台、命令行友好、参数透明，我一直把它当成测序数据清洗的第一选择。
这篇文章适合刚入坑生信、面对一堆 fastq.gz 不知道从哪个参数下手的初学者，也适合流程跑熟了但还是想说清楚每个参数到底在干什么的老手——毕竟很多人的做法是直接从网上抄一段命令改改路径就跑了，参数含义一知半解，出了问题根本不知道往哪儿查。这篇文章就把 Trimmomatic 的底层逻辑、每个参数的细节、双端数据的配对处理、实战命令和常见坑都掰开揉碎讲一遍，看完能直接照着写你自己的清洗流程。
1. 为什么需要 Trimmomatic：先搞清楚它在帮你解决什么问题
1.1 原始数据到底"脏"在哪里
二代测序的原始产出，本质上是一堆由测序仪拍照、碱基识别算法转化出来的短读长（reads），配上对应的质量值（Phred quality score）和序列描述信息，最终以 fastq 格式交到你手里。但这个过程天然会引入三类问题，不处理不行。
第一类是接头残留。文库构建时需要在 DNA 片段两端接上接头，测序时从接头边上的插入片段开始读。当插入片段长度比测序读长还短的时候，测序仪就会一路读过去，把末端的接头序列也读进来，这种现象叫 adapter read-through。双端测序里还有一种更隐蔽的场景：两条短插入片段的两端读长会在中间发生重叠，测序仪会继续读过去，把对方那一段的接头也读进来，这种情况通常让 R1 和 R2 出现回文重叠结构。
第二类是质量退化。测序反应越往后面跑，酶活性下降、荧光信号衰减、相位错乱累积，导致读长末端的质量值普遍偏低。如果把低质量区域留着不处理，比对时会冒出大量错配，变异检测时就会产生大量假阳性位点——这一点做重测序和 RNA-seq 的朋友应该深有体会，差别往往很直观。
第三类是长度分布不理想。文库构建时插入片段有预期分布，但总有些片段偏短、甚至短到根本不具备分析价值。这类超短读长留着只会增加比对软件和组装软件的负担，在转录组里还容易造成多比对（multi-mapping）干扰定量结果。
1.2 它是怎么做到"一站式清洗"的
Trimmomatic 本质上把三类清洗动作打包成了一个工具：按接头/已知序列剪切（ILLUMINACLIP）、按质量剪切（LEADING/TRAILING/SLIDINGWINDOW）、按长度过滤（MINLEN，附带 CROP/HEADCROP 这类硬裁剪）。它的设计哲学就是"一条命令解决全部问题，参数自由组合"。
对比一下其他方案你就知道它好在哪：有些工具只专注接头去除，质量剪切得另外找工具；有些工具做质量修剪但双端配对处理得很粗糙。Trimmomatic 的优势在于，你可以在同一条命令里把接头、质量、长度全部处理完，而且它对双端数据的配对关系处理得非常严谨——具体有多严谨，后面专开一节讲。
1.3 在分析流程里的位置
常规套路是这样的：拿到下机数据，先跑 FastQC 看整体质量分布和接头污染情况，然后跑 Trimmomatic 清洗，清洗完再跑一次 FastQC 验证效果，之后才进入比对、定量或组装阶段。
这个"清洗前看一遍、清洗后看一遍"的习惯很值得养成。Trimmomatic 处理完之后，比对率通常会明显上升，尤其对 16S 扩增子、RNA-seq、基因组重测序这类下游依赖比对的场景，效果立竿见影。而且清洗后的数据量变小了，后续比对和组装的时间也会跟着缩短，这笔账怎么算都不亏。
2. 环境准备与基础命令结构
2.1 运行环境：其实只有一个前提
Trimmomatic 是 Java 程序，运行前先确认机器上有 Java 运行环境，版本建议 1.8 及以上（新版本配合新一点的 JRE 也没问题）。装好后把发布包解压到固定目录，里面通常会有一个 trimmomatic-版本号.jar 的 jar 包，还有一个存放接头序列文件的 adapters 目录。
使用层面的依赖很少，真正的依赖在算力上。处理几百 GB 的 fastq.gz 数据，IO 吞吐量、可用内存、CPU 核数都可能成为瓶颈，后面第 6 节专门讲性能相关的问题。
2.2 命令的基本骨架
Trimmomatic 的命令格式非常固定，建议直接记这个骨架：
java -jar trimmomatic-0.39.jar PE \ -threads 8 \ -phred33 \ input_R1.fastq.gz input_R2.fastq.gz \ output_R1_paired.fastq.gz output_R1_unpaired.fastq.gz \ output_R2_paired.fastq.gz output_R2_unpaired.fastq.gz \ ILLUMINACLIP:adapters/TruSeq3-PE.fa:2:30:10 \ LEADING:3 TRAILING:3 \ SLIDINGWINDOW:4:15 \ MINLEN:36单端模式把 PE 换成 SE，输入输出各给一个文件即可。需要注意：PE 模式下输入两个文件、输出四个文件（两条 paired 和两条 unpaired）；SE 模式输入输出各一个文件；所有处理参数一律放在最后，按标准顺序排列。
2.3 输出文件的命名逻辑
PE 模式的四个输出文件是有讲究的，很多人第一次看到就懵了。*_P.fastq（paired）表示这条读长在 R1/R2 两侧都通过了过滤，配对关系保留完整；*_U.fastq（unpaired）表示另一端的配对被过滤掉了，剩下这一条成了"孤儿"。
孤儿读长在大多数下游分析里不能直接作为配对数据使用，所以 Trimmomatic 单独把它们放一个文件，避免混用。你清洗完之后，通常只把两个*_P文件拿去做后续分析，*_U文件先留着，但大多数场景用不上。个别做单端组装或者做 scaffold 填充的场景可能会用到 unpaired 数据，所以也别急着删。
2.4 第一个能跑通的例子
先拿一小份数据试跑，确认环境没问题：
cd ~/test java -jar trimmomatic-0.39.jar SE -threads 4 \ -phred33 sample_R1.fastq.gz \ sample_trimmed.fastq.gz \ LEADING:3 TRAILING:3 SLIDINGWINDOW:4:15 MINLEN:36这条命令很朴素，但完整走了一遍质量清洗流程：先去掉读长首部的低质量碱基，再去掉尾部低质量碱基，然后以 4 个碱基为窗口滑动、平均质量低于 15 就切掉，最后把长度不足 36 bp 的读长全部丢弃。跑之前最好确认一下数据是 Phred+33 编码还是 Phred+64 编码，命令里的-phred33不能拍脑袋写死，后面有专门一节讲怎么判断。
3. 核心参数深入拆解
3.1 ILLUMINACLIP：接头和污染序列去除
ILLUMINACLIP 是 Trimmomatic 里最复杂的参数，格式是：
ILLUMINACLIP:<接头序列文件>:<种子错配数>:<回文剪接阈值>:<简单剪接阈值>完整看就是ILLUMINACLIP:adapters.fa:seedMismatches:palindromeClipThreshold:simpleClipThreshold。
后面还可以跟两个可选参数：最小接头匹配长度（minAdapterLength，默认 8）和keepBothReads（设为 true 时即使回文剪接把 R1 整个剪掉也保留 R2，默认 false）。
运行时它做两件事。一是简单模式（simple clip）：把读长序列和接头序列做局部比对，只要接头出现在读长的任意位置，且匹配长度达到阈值，就从接头起始位置把后面全部剪掉。二是回文模式（palindrome clip）：专门处理双端读长重叠、两端读长"互相读到对方接头"的情况，它把 R1 和 R2 合并起来检测回文结构，一旦确认就把两端接头区域都剪掉。这个回文模式是 Trimmomatic 的一大特色，处理短插入片段文库（比如双端 150 bp 测序但插入只有 200 bp 左右的文库）时特别好用。
关于接头序列文件，发布包里带了一批常见平台的接头序列 fasta 文件，可以直接选用。但实际情况是接头版本更新频繁，很多测序服务商提供的接头和包里的默认文件对不上。我的习惯是：从建库说明书里找到接头全序列，自己建一个 fasta 文件，只留下真正用到的接头，避免误剪。
注意接头方向。fasta 里每条序列的方向必须是"读长遇到接头时会读到的那个方向"，写反了等于没剪，而且不会有任何报错提示，非常坑。
3.2 SLIDINGWINDOW、LEADING、TRAILING：质量剪切三件套
LEADING:n表示从读长 5' 端开始数，只要碱基质量值低于 n 就逐个去掉，直到遇到第一个质量达标的碱基。TRAILING:n同理，只不过从 3' 端往回处理。这两个参数作用于读长两端，适合处理系统性低质量区域，也是成本最低的剪切方式。
SLIDINGWINDOW:windowSize:requiredQuality是更精细的手段。它以 windowSize 个碱基为一个窗口，每次移动一个碱基，计算窗口内所有碱基的平均质量，只要窗口平均质量低于 requiredQuality，就从窗口位置把读长截断。举个例子，SLIDINGWINDOW:4:15就是每次看 4 个碱基，4 个碱基的平均质量低于 15 就砍掉。
窗口大小怎么选？窗口设大一点（5 或 6）容忍度更高，适合质量整体较稳的平台；设小一点（4）对局部质量波动更敏感，适合那些质量曲线中间偶尔掉坑的数据。我自己的经验是，如果 FastQC 看质量曲线是"开头平稳、末端断崖式下跌"的类型，用TRAILING:3加SLIDINGWINDOW:4:15就够了；如果质量曲线是"波浪形"或者中途有明显凹陷，可以考虑把窗口调大到 5 或者把阈值降到 12，别把有效数据切没了。
3.3 MINLEN、CROP、HEADCROP：长度控制
MINLEN:n把所有清洗后长度短于 n 的读长直接丢掉。它是所有参数里最后执行的过滤动作，配合前面的剪切参数使用。这个参数在 PE 模式下还有个连带效应：某条读长短了，它的配对读长如果也跟着不合格，两条都会进 unpaired 文件；如果只有一条不合格，另一条就会变成孤儿进 unpaired 文件。
CROP:n是保留读长前 n 个碱基，多余的直接切掉，主要用来统一读长标准，比如你想把数据统一规范到 100 bp 再做分析。HEADCROP:n则是从读长开头切掉 n 个碱基，常见应用场景是前 10 个碱基质量普遍差、而且不想用质量剪切慢慢处理的时候，直接一刀切掉。
有些平台在扩增子测序里会在 5' 端引入随机碱基或引物序列，这时候 HEADCROP 就很有用。CROP 和 HEADCROP 千万别搞混，一个是"保留前 n 个"，一个是"切掉前 n 个"，方向完全相反。
3.4 参数组合策略：先接头、再质量、后长度
写参数的时候我建议按这个顺序：ILLUMINACLIP 在最前面，接着 LEADING/TRAILING，然后 SLIDINGWINDOW，最后 MINLEN。这既是绝大多数教程的通篇顺序，也是逻辑上最合理的顺序——先把接头切掉，避免接头区域污染质量计算；再做质量剪切，因为剪切后长度会变化；最后做长度过滤，以清洗后的最终长度为准。
实际测试中我发现，如果顺序反过来（先 MINLEN 后剪接头），很多因为接头残留被算作"较长"的读长会在剪切后被误判为合格而保留下来，这些序列里其实混着大量的接头垃圾，下游比对的时候就会看到一堆比对到接头区域或无法比对的读长。所以顺序这个东西，看起来不起眼，影响是真的实打实的。
4. 双端数据的配对处理逻辑
4.1 PE 模式为什么输出四个文件
这是 Trimmomatic 初学者最容易困惑的地方。PE 模式下输入 R1、R2 两个文件，输出却是四个：R1_P、R1_U、R2_P、R2_U。
逻辑是这样的：清洗过程中，R1 和 R2 各自都可能因为质量或长度不合格而被处理。如果 R1 合格但 R2 不合格，R1 就成了"孤儿"，只能进 R1_U；如果两边都合格，配对进 R1_P 和 R2_P；如果两边都不合格，两条分别进各自对应的 U 文件。这样的设计保证了一件事：凡是留在 P 文件里的读长对，它们的顺序、数量、ID 完全一致，下游比对软件可以放心按配对处理。
4.2 配对信息为什么不能丢
做双端比对（比如用 BWA 或 Bowtie2 的 paired-end 模式）时，软件依赖 R1 和 R2 的配对关系来估计插入片段长度分布、辅助判断比对位置。如果配对关系被打乱，轻则比对效率下降，重则产生错误的比对结果。
这也是为什么我不建议自己在 Perl 或 Python 脚本里手工写循环来"过滤低质量读长"——自己写的脚本很难保证同时处理 R1/R2 的配对同步。Trimmomatic 把这套配对同步逻辑实现得非常成熟，你用它的 PE 模式，P 文件里的配对就是严格配对的，不用额外校验。
4.3 从 paired 和 unpaired 数量能看出什么
跑完之后看一眼日志里的数量统计是有意义的。比如 R1_P 有 400 万条、R1_U 有 100 万条，说明有 100 万条 R1 的配对被丢弃了，整体存活率是 80%。如果你发现 U 文件特别大（比如超过 50%），就要回头看参数是不是太激进了——比如 MINLEN 设太高、或者 SLIDINGWINDOW 阈值设太严，导致大量读长被过度剪切。
实操提醒：在项目里用脚本批量处理多个样本时，清洗完建议顺手统计一下每个样本的 paired 比例，如果某几个样本的 paired 比例明显低于其他样本，大概率是那个样本本身质量有问题，需要单独回去看 FastQC 报告，别硬跑下游。
5. 实战案例：从 FastQC 初检到干净数据
5.1 案例背景
假设我手上有一个模拟项目（就叫它"模拟项目X"），双端 150 bp 测序，共 500 万对读长，压缩后大约 1.5 GB。客户说这个数据是某主流平台产出的，做的是细菌基因组重测序，目标是变异检测和组装。这个场景非常典型，适合拿来完整走一遍。
5.2 FastQC 初检发现了什么问题
拿到数据第一件事，不是跑 Trimmomatic，而是先跑 FastQC。跑完看了一眼报告，三个问题很明显：
第一，测序质量曲线从第 120 bp 开始明显下滑，到 150 bp 时平均质量已经掉到 Q20 以下；第二，过表达序列（overrepresented sequences）里出现了接头序列，说明有相当比例的读长读穿了插入片段、读到了接头；第三，序列长度分布显示大部分读长是 150 bp，但有一小撮集中在 30~60 bp 附近的短片段，这些大概率是建库时的异常产物。
这三个问题对应 Trimmomatic 的三种处理：质量下滑用 TRAILING 和 SLIDINGWINDOW 处理，接头残留用 ILLUMINACLIP 处理，短片段的异常产物用 MINLEN 过滤掉。
5.3 参数选择与命令
基于上面的判断，我最终敲定的命令是：
java -jar trimmomatic-0.39.jar PE \ -threads 16 \ -phred33 \ sample_R1.fastq.gz sample_R2.fastq.gz \ sample_R1_paired.fastq.gz sample_R1_unpaired.fastq.gz \ sample_R2_paired.fastq.gz sample_R2_unpaired.fastq.gz \ ILLUMINACLIP:my_adapters.fa:2:30:10 \ LEADING:3 \ TRAILING:3 \ SLIDINGWINDOW:4:15 \ MINLEN:80参数为什么这么选，逐个说：
接头参数选2:30:10，这是很常见的保守设置。种子匹配允许 2 个错配，回文剪接阈值为 30（要求回文区域匹配率不低于 30/40 左右），简单剪接阈值为 10。对于细菌重测序这种对假阳性敏感的场景，简单剪接阈值设低一点（10）可能会误伤一些恰好跟接头有局部相似的序列，所以我没有用更激进的 7 或 8，而是用 10 做平衡。
MINLEN 选 80 是有讲究的。因为质量从 120 bp 后开始下滑，滑动窗口剪切后很多读长会缩到 120 bp 以下，但如果设得太低（比如 36），那些被切掉半截的短读长还是会留下来，对后续组装是负担；设得太高（比如 120），又会把一批质量其实尚可的读长直接扔掉。80 是从长度分布上看比较稳的一个中间值，保留了足够的信息量，又过滤掉了明显不合格的碎片。
5.4 清洗前后的对比
跑完看日志，500 万对读长里，R1_P 和 R2_P 各剩余大约 420 万条，paired 比例 84%，unpaired 有 80 万条左右，整体存活率符合预期。
清洗后用 FastQC 复测，三个问题都有明显改善：质量曲线在末端的下坠被切掉了，整体看起来平稳多了；过表达序列里接头基本消失；长度分布集中在一个合理的区间。后续比对率从清洗前试跑的 88% 提升到了 96% 左右，变异检测的假阳性位点数也肉眼可见地减少了。
这个案例给到你的参考价值是：任何参数都不是拍脑袋定的，一定是从 FastQC 报告里的具体问题倒推出来的。下次拿到数据别急着跑命令，先花十分钟看 FastQC，能省后面十小时排错。
6. 常见问题与排查技巧实录
6.1 Java 内存不足和线程设置
Trimmomatic 默认使用 Java 虚拟机的默认堆内存，数据量一大就会出现OutOfMemoryError。解决办法是在java后面加-Xmx参数，比如java -Xmx8g -jar trimmomatic-0.39.jar ...。到底给多大，看你的输入数据量级和可用内存，一般是输入压缩文件大小的一到两倍就够。
线程参数-threads在 PE 模式下能有效加速，实测从 4 线程加到 16 线程，处理时间大约是原来的三分之一到四分之一。不过线程数不是越大越好，受限于机器 CPU 核数和 IO 带宽，超过物理核数反而会有调度开销。
6.2 Phred 编码判断错误
命令行里的-phred33和-phred64写错了不会报错，只会静默地产生错误结果——因为质量值被当成另一套体系解析，所有质量相关的参数（LEADING、TRAILING、SLIDINGWINDOW）都会跟着失效或误判。
怎么判断编码？最直接的办法是看 FastQC 的质量分布图纵轴范围。Phred+33 编码的质量值范围通常是 0~41，我们常看到的 Q20、Q30 就在其中；Phred+64 编码的质量范围会从 64 开始往上。还可以手动看一个字符的质量值：fastq 的第四行是质量字符串，ASCII 码减去 33 或 64 得到质量值，如果减去 33 后范围合理（绝大多数在 0~41 之间）就是 phred33，如果减去 64 后范围合理才是 phred64。现在绝大多数平台都是 phred33，但老数据或特殊平台可能还有 phred64，拿到不熟悉的数据源时值得花一分钟确认。
6.3 接头文件匹配不上
如果你确认数据里明明有接头，但 ILLUMINACLIP 剪完 FastQC 复查接头还在，最可能的原因是接头序列文件里的方向和序列不对。
解决办法是：从建库说明书里把接头序列原样复制出来，注意两端接头的互补链关系，Trimmomatic 的默认行为是基于 fasta 文件里的序列及其反向互补来检索，所以文件里一般只需要写正向序列。如果还不确定，可以用一个小测试：跑一个只有 ILLUMINACLIP 参数的命令，输入一小份已知有接头的数据，看输出日志里剪掉了多少条，手动验证。这一步最好在批量处理之前做掉，否则几百个样本跑完才发现接头没剪干净，返工成本很高。
6.4 数据量太大跑得很慢
Trimmomatic 本身是单机程序，数据量大就是会慢。我的经验性建议有三条：第一，用 gzip 格式的输入输出，IO 传输量小很多，虽然压缩会占一点 CPU，但整体通常更快；第二，把输入文件和输出文件放在不同的物理磁盘上，避免读写竞争；第三，合理设置线程数，16 线程一般是个比较舒服的档位。
另外强烈建议用-trimlog参数输出一份剪切日志。它记录了每条读长被剪切的位置和原因，对问题排查极其有用，尤其是当你发现下游分析出现异常、想回头查某条具体读长到底被怎么处理了的时候。一条命令加上这个参数，成本几乎为零，价值却很大。
6.5 结果文件数量对不上
有时候跑完发现四个输出文件的大小明显失衡，比如 R1_P 只有几 MB，而 R1_U 有几百 MB，这说明绝大多数读长的配对被丢弃了。这时候不要急着怀疑工具出了问题，先回头检查 MINLEN 和 SLIDINGWINDOW 是否太激进。
我之前遇到过一段场景：某课题组的 A 同学跑转录组数据，直接用网上抄来的MINLEN:36，结果 paired 比例只有 40%，大量读长被当成孤儿丢弃。后来发现他的原始读长是 50 bp 的单端 RNA-seq 数据，质量本身还行，但 SLIDINGWINDOW 阈值设 20 把很多带 3' 端低质量尾巴的读长整体剪短了，最后全被 MINLEN 40 过滤。调整成SLIDINGWINDOW:4:15加MINLEN:30之后，存活率从 40% 提到 75%。参数是死的，数据是活的，一定要看自己数据的实际情况。
7. 实操心得与过程体会
几个自己攒下来的经验，最后分享给你。
第一，别在全部数据上直接试参数。无论你多急着要结果，都先随机抽 20~50 万条读长做一个小测试集，在小测上把参数调好，再在完整数据上跑。这样一趟下来，参数调整的时间成本极低，还能快速发现数据本身的问题。我用这个办法处理过不少"数据质量差到没法救"的样本，提前就提醒委托方重新建库，而不是等全量跑完才发现。
第二，养成"清洗前后各跑一次 FastQC"的习惯。这一步不仅能验证清洗效果，还能帮你逐步建立经验库——什么样的参数对什么样的质量曲线有效，下次碰到类似数据可以直接套用。
第三，版本锁死。Trimmomatic 的版本、接头序列文件版本、Java 版本，最好在项目文档里记清楚。不同版本的参数行为可能有细微差别，如果后面要复现或者写方法学部分，版本信息写不清楚容易被杂志审稿人追问。我一般会在流程脚本开头加一行注释，记录工具版本和关键参数摘要，防止过了几个月自己都忘了当初是怎么跑的。
第四，有点耐心读日志。Trimmomatic 跑完会在终端打印详细的统计信息，每条参数处理了多少条读长、总存活率是多少，这些都是判断清洗质量最直接的证据。我见过不少人跑完直接把终端清掉，连日志都不存一份，出了问题就无从查起。建议每次处理都把终端输出重定向到一个 log 文件里，存到项目目录，成本几乎为零，后面排查问题全靠它。
最后说一句大实话：Trimmomatic 用熟了其实非常简单，但它的价值恰恰体现在你对参数的理解深度上——同样的数据，参数不同，结论可能完全不同。花点时间把每个参数背后的原理搞清楚，能让你的生信流程稳很多。
