最近几年做动物分子生态和系统发育研究，线粒体基因组已经成了绕不开的标配数据。以前拿线粒体做文章，得靠PCR扩增、克隆测序，或者从已发表的近缘物种里把reads比对回来再拼，流程繁琐，碰到非模式生物更是头疼。MitoZ的出现算是把这个领域的门槛往下拉了一大截。它不需要近缘参考基因组，直接拿全基因组测序的二代数据就能把环状线粒体基因组拼出来，顺带把注释也做了。这篇文章就从实际使用的角度，把这个软件的安装、组装、注释、排错完整过一遍，把我在项目里踩过的坑和验证过的细节都写出来，给准备上手或者正在跟数据较劲的同行一个参考。

1. MitoZ到底是什么：它解决的痛点和设计逻辑

1.1 从“大海捞针”说起：为什么需要专门的线粒体组装工具

做一次普通物种的全基因组测序，下机的数据里绝大部分是核基因组碎片。线粒体基因组在总reads里通常只占很小比例，常见的昆虫、鱼类、软体动物，线粒体比例能到1%到5%就算不错了，有的组织样本处理不好，线粒体reads占比甚至不到0.5%。

用全基因组数据组装线粒体，核心问题就是怎么把这些占比极低的reads从几千万条甚至上亿条序列里捞出来。MitoZ最巧的地方，是它对“捞reads”这件事做了专门的优化。它的第一步并不是直接拼装，而是先用一个预置的起始种子把可能来自线粒体的reads筛选出来，再以这些筛选出去的结果做一轮随机抽样和K-mer频率统计，扩大候选序列池。这个过程有点像一个经验丰富的矿工，先找到几块矿石，顺着矿脉走向慢慢往外扩，而不是把整座山都铲平了再筛。这也是它能摆脱近缘参考基因组依赖的原因，起始种子覆盖的是所有动物线粒体基因的保守区域，不针对某个特定物种。

1.2 一次搞定组装和注释，到底省了多少事

MitoZ从设计上就把“组装”和“注释”拆分成了两个相对独立的阶段，但逻辑上又是连贯的。你不需要先自己跑一轮杂七杂八的脚本把拼接结果处理成某种中间格式，再丢给另一个工具做注释。软件内部已经把基因组序列、坐标、基因结构这些信息整理好了，注释阶段直接读取组装阶段的输出，一个命令接着跑就行。

实际用下来，这种一体化设计最大的好处是复现性，同一批数据、同一个版本，跑出来的中间产物是固定的，不会因为你调换了某一步的处理方式而出现莫名其妙的结果差异。这对需要严格记录数据处理路径的科研项目来说特别重要，审稿人问数据处理细节时，你能把每一步对应的工具版本、参数、产物都交代得清清楚楚。

1.3 这个工具适合谁用

如果你是做动物分类、系统演化、种群遗传、DNA条形码或者食性分析，手上有一批全基因组或浅层基因组测序数据，同时又想顺手拿到完整的线粒体基因组，那MitoZ就是为你设计的。适合的人群包括生态学、进化生物学研究生，做分子鉴定和资源普查的科研人员，以及需要批量处理多个样本的生物信息学支持人员。

需要注意的是，尽管MitoZ对新手已经很友好，但它依然是个命令行工具，你得对Linux基本操作、fastq文件格式这些基础知识有个大概的印象。不需要你会写复杂的脚本，但至少得能看得懂一条报错信息是缺文件还是参数写错了。

2. 环境准备与工具安装：先把地基打牢

2.1 用Conda安装和手动安装怎么选

MitoZ的安装方式主要有两种，Conda安装和从GitHub克隆源码手动装。我个人的建议是，除非你有明确的内网离线安装需求，否则优先用Conda。

conda create -n mitoz python=3.8 -y conda activate mitoz conda install -c bioconda mitoz -y

创建独立的Conda环境这一步很重要。MitoZ依赖的Python库版本说新不新，说旧也不旧，但跟其他生物信息软件放在同一个环境里偶尔会闹脾气。我遇到过的情况是，同一个环境里装了某个版本的numpy，MitoZ的注释步骤就报ImportError，单独建一个环境之后问题再也没有出现过。

如果选择源码安装，流程也不复杂：克隆仓库之后，用pip安装依赖，然后需要手动设置一个环境变量，告诉软件你的数据库文件放在哪里。源码安装对网络条件要求更高，因为要下载依赖和数据库。比较推荐的做法是安装前先把网络环境确认好，避免装到一半断流，留一堆残包。

2.2 配置数据库：这一步卡住了无数人

MitoZ运行过程中需要用到几个外部的数据库，最核心的是NCBI的nt库和taxdump分类信息。软件安装好之后，有一个初始化命令：

mitoz database --install

这个命令会自动下载需要用到的数据库文件。听起来很简单，但实际坑很多。nt库非常大，全部下载通常要几十GB甚至近百GB，而且从NCBI官方源下载的速度在国内网络环境下并不稳定。我的经验是，先手动去NCBI的FTP站点把对应版本的文件下载好，放到本地路径，再用MitoZ的配置命令指定已有数据库位置，这样既可控又可靠。

下载完成后务必检查文件完整性，常见做法是比对一下FTP页面提供的md5校验值。数据库文件不完整时，MitoZ不会立刻报错，而是会在运行到某个分类筛选环节突然提示找不到记录，这时候再回头排查数据库就非常浪费时间。

2.3 硬件需求：别用笔记本死磕王八壳

官方文档给出的最低配置不高，但你如果真拿一台普通笔记本去跑一个鱼类样本的双端150bp测序数据，等组装跑完估计一天都过去了。根据实际经验，我建议内存至少16GB，最好32GB以上，CPU核心数8到16个比较合适。

需要特别注意的是，MitoZ在过滤和组装阶段会生成大量中间文件，建议工作目录所在的磁盘预留至少50GB到100GB的可用空间。如果你的样本很多，每条lane的数据量又很大，把工作目录放在机械硬盘上会导致IO性能严重拖后腿，建议放在固态硬盘或者服务器的高速存储上。我自己有一批贝类样本，数据量不算大，但放机械硬盘上跑，速度明显比放SSD慢三倍以上。

3. 实操全流程：从原始测序数据到完整线粒体基因组

3.1 清洗数据：看似多余实则救命的步骤

MitoZ官方文档强调，输入数据最好是干净的reads，这里的“干净”指已经去除接头、去除了低质量碱基的数据。拿到下机原始数据直接丢给MitoZ，不是说绝对不能跑，但很可能会影响组装完整性。

我建议先用fastp做一轮清洗，具体命令大致是：

fastp -i R1.fastq.gz -I R2.fastq.gz -o clean_R1.fastq.gz -O clean_R2.fastq.gz \ --detect_adapter_for_pe -q 20 -u 30 -l 50 -h fastp_report.html

参数含义不复杂：检测并去除双端测序的接头序列，质量值低于Q20的碱基截掉，单条reads如果有超过30%的低质量碱基就直接丢弃，长度短于50bp的reads也过滤掉。为什么非要处理这一步？因为线粒体基因组的覆盖度本身就靠少数reads撑着，如果reads开头或者结尾带一段低质量序列，组装时可能因为碱基错误造成断裂或误连。清洗后的数据即使有损失，损失的一般也是核基因组的短片段，对线粒体组装没有坏处。

清洗完成后，顺手用FastQC看一眼报告，确认接头残留不多、碱基质量分布正常再往下进行。这一步花不了几分钟，但能避免后面跑半天才发现输入数据有问题。

3.2 第一次组装尝试：直接跑标准命令

MitoZ的组装命令是全流程里最核心的部分，一个比较通用的写法是：

mitoz assemble \ --workdir mitoz_test \ --sample_name sampleA \ --thread_number 12 \ --clipping_percent 0.1 \ --filter_taxa_method 1 \ --filter_taxa_percent 0.5 \ --min_coverage 4 \ --min_length 100 \ --kmer 25 \ --reads_p1 clean_R1.fastq.gz \ --reads_p2 clean_R2.fastq.gz

逐项解释一下关键参数。--workdir是工作目录，所有中间文件都会存在这里，建议一个样本一个独立目录，避免互相干扰。--sample_name是样本名前缀，所有输出文件都会使用这个名字。--thread_number设成CPU核心数或者稍微少一点，给系统留一点余量。--clipping_percent表示在延伸过程中允许末端clipping的比例，0.1是官方推荐的常用值，如果组装连续失败可以适当调高到0.15或者0.2，但要小心，这个值调得过高可能引入错误拼接。--filter_taxa_method控制分类筛选策略，1是常用策略。--kmer是K-mer长度，默认25，对于二代150bp数据来说可以适当调高到31，但要注意并不是越长越好，如果数据覆盖度不高，K-mer过长反而导致图形断裂。

关于覆盖度参数--min_coverage 4，这个值表示一个contig的最低覆盖度阈值，低于这个值的位点很容易是测序错误或极低比例的污染reads。我在实际使用中会把覆盖度阈值设成4或5。如果你很清楚自己的数据质量特别好，设成3也不会出太大乱子，但低覆盖度区域的错误率会上升。

3.3 组装结果什么样的算成功：环状验证是关键

跑完组装命令后，MitoZ会在结果目录里生成一个以.full.fa结尾的fasta文件，这个文件里面可能包含一个或多个contig。理想的输出是拿到一个单一的环状序列，长度跟预期的动物线粒体基因组大小差不多。

常见的动物线粒体基因组大小大致是：后生动物14kb到20kb。脊椎动物一般在16kb到17kb附近，昆虫在15kb到16kb之间，但有些软体动物、寄生虫会有明显偏离。判断组装是否完整，除了看长度，更重要的标准是看这个contig能不能“成环”。MitoZ的输出文件里会有一个标记，说明是不是完整环。更直观的验证方法，是把组装出的序列用minimap2或者BWA比对回自己的reads，看覆盖度是否在全长范围内连续且均匀。有经验的同事会直接看IGV里的覆盖度曲线，如果某个区域覆盖度陡然掉到0，说明那里可能是个装配错误导致的断点。

第一次跑通后，不要急着欢呼。用眼先检查一下输出的fasta序列，观察末端是否存在明显的重复区域。环状基因组的组装结果，序列起点和终点在真实结构上是闭合的，如果起点和终点区域有大片明显高度一致的序列，说明可能拼出了串联重复，属于常见的异常信号。

3.4 完整注释流程：不只是“点一下按钮”

组装完成后，注释阶段是获得基因结构信息的关键一步。命令如下：

mitoz annotate \ --workdir mitoz_test \ --outprefix sampleA \ --thread_number 12 \ --genetic_code 5 \ --clipping_percent 0.1 \ --filter_taxa_method 1

--genetic_code 5是个非常关键的参数。它指定的是线粒体遗传密码表，数字5对应脊椎动物线粒体密码子表。无脊椎动物大多数也用5号密码子表，但棘皮动物是9号表，扁形动物是14号表。不要想当然地套用，一定要去NCBI的遗传密码表页面确认自己的研究对象对应哪张表。选错了密码子表，注释出来的CDS可能早早就出现终止密码子，或者氨基酸序列完全对不上。

注释结束后，MitoZ会按顺序进行蛋白编码基因、rRNA、tRNA的预测和人工比对。蛋白编码基因通常能得到13个标准基因，也就是atp6、atp8、cox1-cox3、nad1-nad6、nad4L、cob（也叫cytb）。rRNA有两类：rrnS和rrnL。tRNA理论上会有22个，且在多数物种里都能全部预测到。

3.5 注释结果的关键校验，必须做两遍

第一遍校验是看基因顺序。不同门类的动物线粒体基因排列顺序存在差异，但某一个特定类群内部通常相对保守。如果注释出来的基因顺序跟同目甚至同科已知物种差得很远，而且你确定组装没有问题，那可能是注释模块的预测出现了错位。这种情况在tRNA密集的区域特别容易出现，因为tRNA基因序列短、二级结构又不明显，预测软件偶尔会漏掉或者重复预测。

第二遍校验是看每个基因是否存在内部终止密码子，特别是蛋白编码基因。线粒体基因的注释比较特殊，有些基因存在不完全终止密码子，比如T或者TA结尾，转录后通过加尾修饰形成完整的终止密码子。MitoZ在注释时会做相应处理，但你如果看到某个基因序列里出现连续多个完整的TAA/TAG，就需要警惕是不是预测出了问题。我会把注释出的每个CDS提取出来，翻译成氨基酸序列，再跟近缘物种的同源基因做一次比对，看有没有意外提前终止。

4. 输出文件解读：别只盯着一个fasta看

4.1 组装目录里都有什么

MitoZ的工作目录结构设计得比较清晰。完成组装后，在workdir下面能看到多个子目录和文件，最重要的是result目录，里面存放的是组装的最终结果。*.full.fa是完整序列文件，推荐优先关注；*.circle.fa在能完整成环时会生成，跟full.fa的区别在于起始坐标可能不同。

另外，目录里还会生成*_filtered.fa、节点文件，以及一个带说明的日志文件。如果结果不理想，需要回到中间步骤排查，这些文件就是排查的依据。日志文件尤其值得关注，它记录了每一步筛选和组装的统计信息，比如参与组装的reads数量、K-mer覆盖度、contig数目。看到结果异常时，先翻日志往往比盲目调参数更有用。

4.2 注释文件怎么看：GFF和序列注释表

注释结果会输出GFF格式的基因注释文件，可以用Geneious、JBrowse或者R里的rtracklayer读取。打开GFF文件，你会看到每一行代表一个注释特征，包括gene、CDS、tRNA和rRNA。比较推荐的做法是，把GFF文件导入Geneious，同时载入组装得到的fasta，这样可以直观地看到序列上基因排布，配合视图能快速发现tRNA是否有重叠、基因间隔区域是否异常过大。

MitoZ还会生成一个“注释表”类型的文件，里面记录了基因名称、起始位置、终止位置、链方向、长度等信息。这个表格可以直接用于后续画基因组圈图，也可以整理进论文附录。

4.3 组装完整度评估：覆盖度的参考价值

MitoZ自己会生成一些覆盖度统计，但我习惯用额外的工具再做一轮交叉验证。具体做法是，取组装出的完整线粒体基因组序列作为参考，把原始clean reads比对回去，然后用samtools depth统计每一位置的覆盖度。覆盖度如果整体均匀，没有局部塌陷，说明组装质量可靠。如果某个区域覆盖度明显偏低，哪怕不是0，也需要警惕该区域是否存在序列错误或者组装歧义。

线粒体基因组的拷贝数在不同组织里差很多，所以覆盖度数值本身没有统一标准。重要的是覆盖度的均匀性，以及跟其他区域相比是否存在异常波动。这点跟核基因组组装评估的思路是一样的，只是线粒体基因组小，更容易一眼看出问题来。

5. 高频报错与排查实录：那些年我们踩过的坑

5.1 组装产物碎片化或直接失败怎么办

这是使用MitoZ时最常见的痛点。明明数据量不小，跑完却只拼出一个几百bp的contig，或者干脆没有产物。第一优先级排查的是组装参数，把--kmer往小的方向调整，比如从25降到21或者19；K-mer缩小后敏感度更高，更容易把低覆盖度的线粒体reads连接起来，但代价是可能产生更多噪音contig。

第二个排查点是数据质量，回到fastp报告里确认是否存在大量未去除干净的接头残留。接头残留对组装的破坏力非常大，它会让reads首尾的K-mer出现系统性的假重叠，导致组装图出现错误的环状结构。第三个排查点则是是否存在严重的物种污染。如果样本在采集时混入了寄生或共生生物，组装结果可能拼出的是污染物种的线粒体，并非目标序列。这时候可以利用MitoZ的分类筛选功能，调整--filter_taxa_method相关参数，或者在比对结果中检查最相似的分类单元是不是自己的目标物种。

5.2 注释出来的tRNA数量不够数

正常动物线粒体应该有22个tRNA，但MitoZ偶尔会预测不全。常见原因是tRNA基因序列变异较大，软件默认的搜索窗口没有覆盖到。我的处理策略是，先把GFF文件里已有的tRNA位置看作有效范围内锚点，提取周围的间区序列，然后用ARWEN在线服务或者MITOS的独立版再预测一遍。

这个做法很有效，特别适合那些tRNA容易发生基因重排的类群，比如软体动物、环节动物。如果间区序列实在太短，预测工具没有足够的参考信息，也可以直接把整条线粒体基因组序列丢给MITOS在线服务器做一轮辅助注释。MITOS的结果跟MitoZ交叉比对后，tRNA的数量基本就齐了。

5.3 内存溢出或进程被杀

内存溢出通常发生在两个阶段。第一阶段是reads过滤和K-mer统计，第二段是组装图构建和简化。如果内存不够，优先考虑减少--thread_number，因为多线程并行在某些环节会额外占用内存。其次可以检查是否同时跑了多个样本，如果有多条任务并发，错开运行时间。

还有一个很隐蔽的坑，是在软件过程中使用临时目录。如果系统的/tmp容量很小，运行大样本时可能会因为临时文件写满磁盘而终止。在命令行之前设置export TMPDIR=/path/to/large/disk可以避免这个问题。

6. 常见问题速查表：一项一项照着查

表格里提到的核线粒体假基因，也就是NUMTs，是线粒体组装的“隐藏杀手”。NUMTs是核基因组中插入的线粒体片段，长度从几百bp到几千bp不等。数据筛选时如果恰好捕抓到大量高度相似的NUMTs，组装时可能把这些片段误当成线粒体的一部分，导致组出来的基因组比实际偏长或出现异常重复区。遇到这种情况，可以把组装序列做一轮BLAST搜索，看全长比对到已知动物线粒体的覆盖率是否接近100%，如果明显偏低，考虑重测序鉴定的样本材料是否富含核基因组污染。

7. 从注释结果往下走：它能支持哪些下游分析

7.1 系统发育重建

拿到注释好的线粒体基因组，最常见下游分析是系统发育重建。你可以从GFF文件里提取13个蛋白编码基因的核苷酸序列，用对应氨基酸序列做比对后再反转为密码子比对，这能避免因密码子结构破坏而造成的比对误差。线粒体基因组也能用于贝叶斯或最大似然法建树，常用软件是IQ-TREE、RAxML、MrBayes。

MitoZ组装注释的多物种结果可以直接整合成一个矩阵，但需要留意物种间基因顺序的差异。如果基因顺序不一致，建议把每个基因独立提取、独立比对、再串联成超级矩阵。tRNA和rRNA序列较短，是否纳入矩阵需要根据研究问题判断，如果目标是深层系统关系，更推荐只用13个PCG。

7.2 选择压力与适应性进化

线粒体蛋白编码基因是研究选择压力的热门对象。把注释出的CDS翻译成氨基酸，用PAML或者HyPhy计算每个基因或每个位点的dN/dS值，可以评估哪些基因受到正选择。MitoZ提供的基因结构注释比较准确，能直接支撑这类分析，不需要再手工整理外显子边界。

但做选择压力分析时，一定要严格检查序列比对质量，并进行去gap处理。线粒体基因长度虽然短，但一个错误的密码子插入会让整个下游结果失真。比对后建议手动剔除含有frameshift的序列或重新检查该物种的注释。

7.3 基因重排与基因组结构变异

有些类群的线粒体基因组会发生基因重排，tRNA被认为在重排中扮演核心角色。如果你发现自己的样本基因顺序跟同一大类的已知物种不一致，这就是个不错的科学故事点。用MitoZ注释出的GFF文件可以直接做基因排列的可视化，常用工具包括CREx或者手工绘制圈图结合tRNA位置标注。

基因重排分析时，务必以tRNA为锚定物。线粒体基因组的重排通常是局部倒位或者tRNA滑动造成的，单纯看PCG顺序容易错过关键信号。需要把22个tRNA全部比对确认后再下结论，这也是前面反复强调要补全tRNA注释的原因。

7.4 样本鉴定与种内变异

MitoZ也能用于物种鉴定。因为组装不依赖近缘参考，理论上遇到未经充分研究的类群也可以直接拼出线粒体基因组。拿到序列后，提取COI或者cytb区域，在NCBI的GenBank里做BLAST，用来判断物种归属或者发现疑似隐存种。

更进一步，如果你有一个种群的多个体数据，虽然跑全基因组组装成本偏高，但可以用浅层测序配合MitoZ批量拼出线粒体基因组，再做种群层面单倍型网络、遗传多样性分析。我见过一些同行用10x左右的浅层测序数据跑MitoZ，效果出乎意料地好，前提是测序文库质量过关。

8. 性能调优与批处理经验

8.1 多个样本并行跑还是串行跑

MitoZ对CPU和内存的占用都是动态的，组装阶段内存峰值往往出现在构建K-mer图谱时。如果你需要在服务器上批量处理几十个样本，最稳妥的做法是每个样本一个独立工作目录，同时并行两到三个任务，观察资源占用后再逐步增加并行度。一次性开十个任务，很可能因为内存互相抢占导致所有任务一起失败。

批处理时，写一个简单的Shell循环或者Snakemake流程会更省心。一个粗糙的循环加日志输出就能满足大多数需求：

for sample in A B C D; do mitoz assemble --workdir ${sample}_out --sample_name ${sample} \ --thread_number 8 --clipping_percent 0.1 --filter_taxa_method 1 \ --filter_taxa_percent 0.5 --min_coverage 4 --min_length 100 \ --kmer 25 --reads_p1 ${sample}_R1.fastq.gz --reads_p2 ${sample}_R2.fastq.gz \ > ${sample}_assemble.log 2>&1 done

需要提醒的是，循环里的工作目录一定要用样本独立命名，避免多个任务同时写入同一个目录导致文件覆盖，这个错误特别隐蔽，有时甚至不是覆盖，而是两个任务同时读写同一个临时文件，直接产生不可复现的结果。

8.2 数据量过大的降采样策略

有些样本是深度的全基因组测序，一个样本的reads达到几亿条。这种情况下全部参与组装会让效率低下，但线粒体基因组的组装本身并不需要那么高的覆盖度。官方文档和社区经验都支持对reads进行降采样，只取其中一部分数据参与组装。

一个简单做法是用seqtk随机抽取：

seqtk sample -s 100 clean_R1.fastq.gz 5000000 > sub_R1.fastq.gz seqtk sample -s 100 clean_R2.fastq.gz 5000000 > sub_R2.fastq.gz

这里用固定的随机种子100保证双端文件抽取的reads一一对应。抽取500万对reads通常对绝大多数动物线粒体基因组组装都足够。如果数据来自低线粒体含量的样本，可以先不降采样直接跑一次，发现覆盖度不足再补充reads。降采样的好处不仅是提速，还能减少低复杂度区域内错误K-mer的引入。

8.3 结合三代测序数据提升完成度

虽然MitoZ主要在二代数据上工作，但有些物种的线粒体基因组存在大片重复区域或极高AT含量区域，二代数据怎么拼都差一段。这几年我试过一个比较有效的组合策略：先用MitoZ粗组装得到大致结构，再利用ONT或者PacBio测序得到的读长序列，通过minimap2比对回粗组装结果，把长reads覆盖不上的缺口补齐。

需要注意的是，三代reads的测序错误率偏高，对线粒体这种小基因组来说，建议先用medaka或racon做一轮polish，再把polish后的序列结合MitoZ注释结果做最终校正。三代数据补齐组装缺口、二代数据保证基准确确度，这个组合基本能解决我遇到过的所有疑难样本。

9. 版本选择与后续维护

MitoZ目前的版本迭代不算频繁，因为核心功能已经比较稳定。日常使用我推荐选择正式发布版，而不是仓库里最新的开发分支。开发分支有可能修复了一些问题，但也可能引入新的不稳定因素，不适合用于正式项目数据分析。

如果你正在进行一个会持续好几年的物种资源调查项目，建议固定一个MitoZ版本并记录完整conda环境的导出文件，方便后续年份的数据保持同一标准。环境导出命令是：

conda env export > mitoz_environment.yaml

这样做的目的，是为了保证2024年跑出来的结果和2026年跑出来的结果之间不会因为软件版本变动而产生不可比的差异。这在涉及多批次样本、后续需要合并数据分析的项目里特别重要。

我个人在实际操作中最深的一点体会是：MitoZ虽然一键式设计很友好，但真正决定结果的还是预处理环节和人为校验环节。转录组数据里哪怕有一点点接头残留、有一点参数选择上的偷懒，最后都会反映在注释结果的异常上。把“洗完数据、跑完流程、回头人工校验一圈”当成标准动作，你的线粒体基因组结果基本就是稳的。如果你现在正在被某个样本的组装问题卡住，不妨按这篇文章里的排查顺序一步步来，大概率能找到突破口。