2026年4月这场以“微生物组-扩增子二、三代16S/ITS分析和可视化”为主题的系列技术研讨,让我终于有机会把过去几年在十几个项目里反复踩过的坑系统梳理了一遍。和同行交流时我最大的感受是:很多人对“扩增子分析”的印象还停留在跑一遍QIIME2出几张PCoA图,但这两年二三代测序交替、ASV取代OTU、物种注释数据库更新、统计方法迭代,整个分析链路已经和五年前完全不是一回事。这篇文章不打算写成会议纪要,而是把研讨会上被追问最多、也是结果最容易出问题的几个节点完整拆开:二三代平台怎么选、实验设计阶段哪些细节会毁掉整个项目、从原始数据到特征表的上游工具链怎么搭、下游统计和可视化怎么组合才能把生物学故事讲清楚,以及几乎人人都遇到过的环境配置和文件报错该怎么排查。适合所有正在做或正准备做16S/ITS扩增子分析的研究生、科研人员和转行做微生态的技术从业者参考。
1. 二三代测序同台竞技:16S/ITS扩增子分析的技术变局
1.1 二代与三代的核心差异:读长、通量与错误率的三角权衡
扩增子测序这个领域,过去十年的绝对主力是二代测序(NGS)。以Illumina MiSeq为例,PE250/PE300的读长配置覆盖16S rRNA基因的V3-V4高变区(约460 bp)完全足够,真菌ITS1或ITS2片段(约300-400 bp)也不在话下。短读长的核心优势是单碱基测序错误率极低(通常低于0.1%),加上通量高、成本可控、分析流程高度成熟,使得它至今仍然是绝大多数微生态研究的首选。
但短读长带来的硬伤也很明显:16S全长约1500 bp,含V1-V9九个高变区,二代测序只能覆盖其中两到三个。这意味着在分类分辨率上,二代基本止步于“属”水平,很多亲缘关系很近的物种在V3-V4区间几乎没有差异。三代测序则把这个问题直接掀翻了。PacBio的HiFi模式(CCS)能稳定产出15-20 kb的读长,测16S全长属于“降维打击”,单分子准确率经过循环一致性纠错后可以达到99.8%以上;Oxford Nanopore的读长更长,极限情况下能覆盖16S-ITS-23S整个操纵子区域,虽然单次错误率较高,但配合聚类纠错策略,近年来的表现已经足够进入常规应用。
三者之间的权衡,我常用一个表格来总结:
| 维度 | Illumina(二代) | PacBio HiFi | Nanopore |
|---|---|---|---|
| 典型读长 | 250-300 bp | 15-20 kb | 10 kb以上 |
| 16S覆盖范围 | V3-V4等个别高变区 | 全长(V1-V9) | 全长甚至更远 |
| 单碱基准确率 | 99.9% | 99.8%(HiFi) | 90-97%(原始) |
| 分辨率 | 属水平为主 | 部分可达种水平 | 经过纠错可达种水平 |
| 单样本成本 | 低 | 中高 | 中等 |
| 分析流程成熟度 | 极高 | 中等,在快速成熟 | 中低,工具碎片化 |
这里要解释一个容易被忽视的逻辑:三代能“分到种”,本质不是算法更聪明,而是信息量变大了。16S的九个高变区散布在保守区之间,只有全长的变异信息才足够支撑种水平的系统发育区分。读长决定了信息上限,这是物理层面的天花板,后面怎么去噪、怎么聚类都是在这个上限内做文章。
1.2 三代测序入场后,实验设计必须重新回答的三个问题
很多人在三代测序刚普及时容易犯一个错误:直接把二代的实验设计方案原封不动搬到三代上。实际上有几个问题必须重新想清楚。
第一个问题是测序数据量。二代16S大家习惯了每个样本5-10万条reads,甚至有人做到20万以上。但三代如果还是这个量级,成本会非常吓人。由于每条序列都是全长且高质量,每个样本3000-10000条HiFi reads已经能覆盖绝大多数环境样本的群落主体。当然,如果关注稀有物种或者预期极端高多样性(比如土壤),建议先用预实验的稀释曲线判断,不要拍脑袋决定。
第二个问题是引物选择。二代用341F/806R做V3-V4是通用方案,三代则普遍推荐27F/1492R这类全长引物。但全长引物的扩增效率在不同门类之间差异比V3-V4引物更明显,比如某些古菌和放线菌的匹配度就偏低。建议先用目标样本类型的已有扩增子数据做一次in silico评估,甚至直接跑个梯度PCR验证。另外需要注意,引物选择直接影响后续物种注释的数据库匹配,改引物意味着分类器可能也要重新训练。
第三个问题是样本混池和barcode策略。三代平台单次运行的barcode数量通常比二代少,样本量大的项目需要设计多轮混池方案,这时要充分考虑barcode跳跃(index hopping)带来的交叉污染风险。我的习惯是在文库制备时设置阴性对照和阳性模拟菌群对照(如Zymo的mock community),专门用来评估交叉污染率。这些对照在二代流程里是可选项,在三代流程里我建议做成必选项。
2. 从样本采集到数据交付:扩增子项目前期的关键节点
2.1 不同样本类型的采集、保存与送测规范
样本质量决定分析质量,这句老话在扩增子项目里体现得淋漓尽致。研讨会上被问得最多的就是水体和沉积物样本的送测问题,很多人拿到海水或底泥样本后不知道该怎么处理。海水样本的微生物量通常较低,采集时需要用0.22 μm的聚醚砜滤膜过滤,记录过滤体积(一般建议至少1-2 L,低生物量水体需要更多),过滤后将滤膜折叠放入无菌冻存管,液氮速冻后转-80°C保存。这里最容易被忽略的是:过滤体积不够会导致后续DNA提取量不足,而提取量不足会被迫增加PCR循环数,进而放大嵌合体和偏好性扩增,这是整个项目数据质量崩塌的起点。
底泥和沉积物样本的问题正好相反,微生物量充足,但腐殖酸和多糖等PCR抑制物含量极高。采样时要尽量避开石块和植物残体,取表层以下0-5 cm的代表性分样,多点混合后再分装。DNA提取建议使用专门的土壤/沉积物提取试剂盒(如DNeasy PowerSoil系列等),提取后用Nanodrop和Qubit双重质检,A260/230比值低于1.5说明腐殖酸残留严重,需要考虑额外的纯化步骤。
无论是哪种样本类型,有几条铁律是通用的:
- 样本采集后尽快处理,无法立即提取DNA时必须-80°C保存,避免反复冻融;
- 每组至少设置3-5个生物学重复,这是后续做PERMANOVA和差异分析的基本底气;
- 必须设置阴性对照,包括DNA提取空白和PCR空白,用来识别试剂污染和交叉污染;
- 如果项目跨批次采样,尽量同一批次完成DNA提取和文库构建,把批次效应摁在源头。
2.2 测序平台与引物选择:对后续分析路径的影响
平台和引物的选择,看起来只是“实验设计”的一小步,实际上直接决定了后面所有分析能不能顺利开展。16S扩增子首选V3-V4区的“标配”地位至今没有动摇,但如果你所在领域发表在更高影响因子期刊上的文章普遍用V4区(如515F/806R),最好尊重领域习惯,因为审稿人会对引物选择提出质疑。V4区片段更短(约250 bp),在部分测序平台上可以做更高通量的混样,但分辨率略低于V3-V4,这是一个需要权衡的点。
真菌群落分析则是ITS1和ITS2的选择问题。ITS1在真菌物种鉴定中信息量通常更大,但序列长度变异范围广,部分类群(如某些酵母)的ITS1长度差异极大,扩增效率不稳定;ITS2相对保守,扩增更稳定,对种水平的区分力也在提升。目前的趋势是很多研究同时扩增ITS1和ITS2做联合分析,或者在UNITE数据库框架下比较两个区域的注释效果再决定。
确定引物后,另外一个容易翻车的环节是和测序公司对接。我建议在送测单上明确标注以下信息:测序平台(MiSeq/NovaSeq/PacBio Sequel系列/Nanopore)、测序策略(PE250/PE300或CCS模式)、每个样本目标reads数、是否需要去barcode、数据交付格式(纯fastq还是带QIIME2 artifact)。不要默认公司会帮你做引物切除,很多公司交付的fastq里是包含引物的,这会直接干扰后续质控流程。拿到数据后第一步永远是用MultiQC或fastqc做全局质量检查,任何跳过这一步直接跑DADA2的行为都是给自己埋雷。
3. 上游分析流程选型:从原始数据到特征表的完整链路
3.1 二代数据的质控、拼接与ASV聚类:QIIME2和DADA2的实际操作
二代扩增子数据的上游分析,目前最主流的路线是QIIME2 + DADA2插件。我自己的标准流程可以浓缩成这几步:
# 导入原始数据(casava/single-end or paired-end) qiime tools import \ --type 'SampleData[PairedEndSequencesWithQuality]' \ --input-path manifest.tsv \ --output-path demux.qza \ --input-format PairedEndFastqManifestPhred33V2 # 可视化质量分布,决定截断参数 qiime demux summarize --i-data demux.qza --o-visualization demux.qzv # 去引物(很多公司交付数据未切引物,这步不能省) qiime cutadapt trim-paired \ --i-demultiplexed-sequences demux.qza \ --p-front-f CCTACGGGNGGCWGCAG \ --p-front-r GACTACHVGGGTATCTAATCC \ --o-trimmed-sequences trimmed.qza # DADA2去噪,得到ASV特征表 qiime dada2 denoise-paired \ --i-demultiplexed-sequences trimmed.qza \ --p-trim-left-f 0 --p-trunc-len-f 280 \ --p-trim-left-r 0 --p-trunc-len-r 220 \ --p-max-ee-f 2 --p-max-ee-r 2 \ --o-table table.qza \ --o-representative-sequences rep-seqs.qza \ --o-denoising-stats stats.qza这里每一步都藏着经验。truncLen参数绝对不能照抄网上的教程,必须结合demux.qzv里的质量图来判断。我见过太多人因为截断长度不合适,把高质量序列砍掉太多导致overlap不足,或者保留低质量碱基导致后续嵌合体率飙升。overlap至少要有20 bp,否则拼接必然失败。另外一个容易被忽略的参数是--p-max-ee,它代表每条序列允许的最大预期错误数,默认2是通用选择,但低质量样本可以把两个末端分别设为2和3,能在保留更多序列的同时保证准确率。
之所以强调ASV而不是OTU,是因为97%聚类存在根本性的信息丢失:两个只有一个核苷酸差异的ASV如果被聚成一个OTU,后续所有多样性计算、差异分析都会在这个“合并”上失真。而且ASV具有可重复性,不同研究、不同时间跑出来的结果可以直接合并比较,OTU则每次聚类都可能不同。除非是历史数据需要对齐,否则新项目强烈建议全部走ASV路线。
3.2 三代数据:lima/ccs处理与去噪工具的选择
三代扩增子数据分析目前还没有形成像QIIME2这样统一的一站式平台,但核心流程已经比较清晰。以PacBio为例,平台交付的数据通常是带barcode的subreads bam文件,处理链路是:lima去除barcode → ccs生成HiFi一致性序列 → 长度过滤(保留1200-1800 bp区间的16S全长) → 去噪聚类 → 物种注释。
# 去除barcode lima movie.bam barcodes.fasta demux.bam --is-barcode # 生成HiFi一致性序列 ccs demux.bam ccs.bam --hifi-kinetics # 过滤长度后输出fastq samtools view -h ccs.bam | awk '...' | samtools bam2fq - > ccs.fastq去噪这一步目前最常用的方案是DADA2的denoise-ccs函数,它会利用CCS序列本身的质量分数做误差建模,效果比单纯聚类要好。也可以考虑actc(Absolute Copy number and Taxonomy Classifier)这套专门为三代扩增子设计的流程,它整合了barcode处理到物种注释的全链路。Nanopore这边,guppy/basecaller做完碱基识别后,用chopper或porechop做接头和barcode去除,随后通过vsearch聚类成OTU,或者用精度更高的但支持长读长去噪工具(如qcat、yacrd等)处理。
三代数据有自己特有的坑。第一个是嵌合体,由于全长扩增片段较长,PCR过程中的不完全延伸更容易形成嵌合体,所以DADA2的removeBimeraDenovo步骤绝对不能省,而且建议把方法来从consensus换成pooled,效果更保守。第二个是barcode跳跃,lima的去重参数要设置好,否则样本间污染无法溯源。第三个是均聚物错误,尤其Nanopore平台在同聚物长度上容易出错,可能导致ASV真假难辨,所以要么接受一定程度的分辨率损失做OTU聚类,要么用HiFi数据避免这个问题。
3.3 物种注释数据库的匹配问题:16S与ITS的差异
扩增子分析里,物种注释数据库的选择对结果的影响程度经常被低估。同一批数据,用不同数据库注释,门水平可能看不出差别,但到属和种水平结果相差甚远。16S领域目前主流选择是SILVA(持续更新,覆盖细菌、古菌和真核微生物)和Greengenes2(近年来社区热度回升),RDP的应用逐渐减少。GTDB是基因组分类学的产物,更多用于宏基因组,但因其分类框架更科学,在扩增子注释中的应用也在增加。ITS方面基本是UNITE的天下,它专门针对真菌ITS区域做了动态聚类,物种覆盖度和更新频率都是最优的。
| 数据库 | 适用区域 | 特点 | 更新状态 |
|---|---|---|---|
| SILVA | 16S/18S/23S/28S | 覆盖广,注释质量高 | 持续维护 |
| Greengenes2 | 16S | 统一了系统发育框架 | 近年在推进 |
| RDP | 16S | 历史版本多 | 基本停止更新 |
| GTDB | 16S/基因组 | 分类体系更贴近基因组进化 | 快速更新 |
| UNITE | ITS | 真菌注释首选,含动态聚类 | 持续维护 |
数据库选定后的关键操作是训练分类器。QIIME2官方提供预训练的Naive Bayes分类器,但那是基于特定引物区域训练的,换成V3-V4以外的引物效果会大打折扣。正确做法是用自己的引物区域从SILVA/UNITE提取对应片段,然后重新训练分类器。这一步看起来麻烦,但对属水平注释准确率的提升非常明显。ITS还有一个特殊问题:由于ITS序列变异极大,UNITE的“物种”聚类有时会把同一物种的不同菌株拆成多个OTU/ASV,注释时需要结合序列相似度和系统发育位置综合判断,不要盲信自动化注释结果。
4. 下游统计分析与可视化:把群落差异讲清楚
4.1 Alpha/Beta多样性分析的正确打开方式
拿到特征表之后,第一个关卡是标准化。很多教程还在教“全体样本抽平到最低测序深度”,这个方法操作简单但争议很大:抽平会丢弃有效数据,导致稀有物种的检出率下降,而且抽平后的计数不等同于真实丰度。更推荐的做法是保留原始counts,在计算Beta多样性时用CSS(cumulative sum scaling)或TMM标准化,或者在phyloseq里用transform_sample_counts按总丰度归一化。如果非要抽平,至少要把抽平后的数据做敏感性分析,看结果是否依赖抽平深度。
Alpha多样性是微生物群落的“内部生态”描述。最常用的指标有四个:Observed features直接数ASV数量,代表观察到的丰富度;Chao1通过稀有种出现频率估计总丰富度;Shannon综合考虑丰富度和均匀度,是最常用的综合多样性指数;Faith's phylogenetic diversity(Faith's PD)则把系统发育信息纳入计算,适合关注进化多样性的研究。用菌群多样性做组间比较时,建议至少同时报告Observed features和Shannon,必要时加上Faith's PD,审稿人对单指标结论通常不太买账。
Beta多样性是“组间差异”的核心量化手段。Bray-Curtis距离基于丰度,是生态学经典选择;Jaccard只看有无,对稀有物种敏感;UniFrac系列(未加权/加权)引入系统发育树,分别强调稀有谱系和优势谱系。排序可视化常用PCoA和NMDS,NMDS要注意stress值,小于0.2才算可以接受的排序结果。组间差异检验则用PERMANOVA(adonis2),在R里一行代码就能跑:
library(vegan) adonis2(dist_matrix ~ group + covariate, data = metadata, permutations = 999, by = "terms")这里必须提醒一个坑:PERMANOVA对组内离散度敏感,如果两组内部的样本分散程度差异很大,PERMANOVA的显著性可能是离散度差异而非位置差异,最好同时跑一个betadisper检验来排除。另外,如果实验设计是配对或区块化的,一定要在strata参数里指定分组结构,否则自由度算错会得到虚假的显著结果。
4.2 差异物种筛选的常用方法与阈值设定
“哪些物种在组间显著差异”是扩增子项目最常被问的问题,也是最容易做错的分析。很多文章还在用LEfSe,但LEfSe基于Wilcoxon检验且不控制多重比较,结果已经被不少审稿人质疑。我更推荐的做法是:如果手里有原始counts,用DESeq2或edgeR这类针对高通量计数开发的模型;如果担心组成性数据的假阳性,用ANCOM-BC或ALDEx2这类考虑了成分数据特性的方法。
以DESeq2为例,输入是特征表和分组信息,关键参数是padj(经BH校正的p值)和log2FoldChange的绝对值。常用的阈值是padj < 0.05且|log2FC| > 1(即两倍差异),但这不是金科玉律,样本量小的时候可以适当放松到|log2FC| > 0.6,前提是在验证集中能重复出来。还有一个经验性建议:差异物种筛选一定要设置最低丰度过滤,比如要求ASV在至少20%的样本中出现且平均相对丰度大于0.01%,否则大量单样本出现的极低丰度ASV会淹没有生物学意义的信号。
多重检验问题也是重灾区。一个样本动辄几千个ASV,每个都做统计检验,未校正的p值几乎没有参考价值。BH校正是最低要求,如果差异ASV数量巨大,可以换更保守的Bonferroni校正或者用sva包做批次效应校正。另外,不要忽略效应量(effect size),只报p值不报丰度差异倍数,是很多论文被质疑的主要原因。
4.3 可视化工具矩阵:phyloseq、ggplot2和在线平台怎么选
可视化是扩增子分析里最直观也最出彩的环节。工具选择上,我的建议是“R为主,在线为辅”。phyloseq是R里整合OTU/ASV表、样本元数据、系统发育树和分类表的瑞士军刀,所有常见分析都能做,出图数据还能无缝交给ggplot2做深度定制。MicrobiomeAnalyst这类在线平台的优势是零代码,上传特征表和元数据就能出PCoA、热图、LEfSe柱状图等,适合快速探索和教学演示,但自定义空间有限,出版级图表基本还是要回到R。
| 工具 | 学习成本 | 灵活性 | 适合场景 |
|---|---|---|---|
| phyloseq | 中 | 高 | 一站式分析,R用户首选 |
| ggplot2 | 中高 | 极高 | 最终出版级定制图表 |
| MicrobiomeAnalyst | 低 | 中 | 快速出图,零代码入门 |
| Krona | 低 | 低 | 交互式群落组成展示 |
| GraPhlAn | 中 | 高 | 环形分类树,系统发育全景 |
| Cytoscape | 中 | 高 | 共现网络图 |
具体的图表类型,我按项目汇报和论文发表两个场景区分。汇报场景适合用Krona做交互式物种组成图,鼠标点进去就能看到不同层级分类的占比,观众体验远好于静态饼图;论文场景则要回归几个“标准动作”:稀释曲线展示测序深度,箱线图展示Alpha多样性组间差异,PCoA/NMDS加置信椭圆展示Beta多样性,门水平堆叠柱状图展示群落结构,热图展示丰度聚类,火山图或柱状图展示差异物种。这里有一个配色建议:不要用默认的ggplot2配色,尤其是色盲朋友可能完全看不出红绿差异,推荐使用RColorBrewer或viridis的色盲友好调色板。
发表级图表的硬性标准,前期是花时间调好的:TIFF格式、300 dpi、字体不小于7 pt(通常用Arial或Helvetica)、图例不遮挡数据。我一般用ggsave统一控制输出,一行代码解决问题:
ggsave("PCoA_16S.tiff", plot = p, width = 6, height = 4, dpi = 300, bg = "white")5. 实操中的高频故障与排查记录
5.1 Windows本地环境配置与DLL加载失败这类报错怎么处理
研讨会现场有人带着笔记本上来问了一个报错,原话是这样的:“OSError: [WinError 1114] 动态链接库(DLL)初始化例程失败。Error loading ‘C:\Users\xxx.conda\envs\pytorch\lib\site-packages\torch\lib\c10.dll’ or one of its dependencies.”这类问题在本地跑Python/R环境时非常典型,尤其是通过conda管理多个虚拟环境之后。WinError 1114出现的直接原因是某个DLL的依赖项缺失或版本不匹配,可能是Visual C++ Redistributable没有安装,也可能是conda环境下某个底层库(如OpenMP、MKL)的版本冲突。
排查链路建议按这个顺序走:先装最新版Microsoft Visual C++ Redistributable并重启,解决多数系统级DLL缺失;仍然是1114的话,用Dependency Walker或Visual Studio的dumpbin工具定位c10.dll依赖的哪个具体DLL失败;排查后确认是环境损坏的,直接重建环境,不要试图修补。重建时用conda-forge单一channel,并锁定关键库版本:
conda create -n qiime2-env python=3.9 -c conda-forge conda activate qiime2-env conda install -c conda-forge mamba mamba install -c conda-forge nextflow dada2-python我的个人建议是:不要在一台Windows主力机上部署重量级扩增子分析环境。不是Windows不行,而是大量生信工具链的依赖测试都围绕Linux展开,Windows上经常要额外处理路径分隔符、DLL命名和权限问题。现在WSL2已经非常成熟,直接在WSL2里装conda环境,性能和原生Linux几乎没有差别,这是性价比最高的方案。
5.2 Linux服务器分析环境的搭建与常见坑
上了Linux服务器,问题通常从“软件装不上”变成“权限不够”和“环境混乱”。最常见的一个报错是“The directory ‘/home/linux/.cache/pip/http’ or its parent directory is not writable”,这几乎都是pip缓存目录权限没配好导致的。解决方法很简单:
mkdir -p ~/.cache/pip chmod -R 700 ~/.cache/pip # 或者在pip命令里指定临时目录 pip install --cache-dir=/tmp/pip-cache some-package更重要的还是环境管理习惯。我见过太多人在服务器上直接pip install把系统Python搞挂,或者在base环境里装了上百个包最后互相冲突。正确的做法是每个项目独立conda环境,用environment.yml固定版本并随项目归档:
conda env export > environment.yml conda env create -f environment.yml服务器上跑大样本项目的另一个痛点是内存和磁盘。DADA2的learnErrors和denoise步骤在小样本量时毫无存在感,但几百个样本同时跑时内存占用轻松超过几十GB,建议先用subset或分批次跑,再合并特征表。磁盘方面,原始fastq文件、中间文件、QIIME2 artifact、系统发育树计算文件加起来很容易超过几百GB,开工前先检查服务器磁盘配额,并定期清理中间文件。
5.3 结果解读中的逻辑陷阱与审稿人视角
分析跑通了、图表出完了,真正的考验才刚刚开始:怎么解读结果。扩增子数据有一个天然陷阱——它是成分数据(compositional data),每个样品中各分类单元的丰度总和为100%,一个类群相对丰度的上升,未必意味着绝对数量增加,也可能只是其他类群减少了。所以看到某个菌属在疾病组显著富集时,先问一句:绝对定量(qPCR)验证过吗?没有的话,措辞只能说是“相对丰度升高”,不能说是“数量增多”。
另外一个高频误读是把相关性当因果性。菌群与某个环境因子的关联,可能是菌群影响了环境因子,也可能是环境因子塑造了菌群,更可能是因为共同受第三个变量驱动。真要说因果,需要做移植实验、无菌动物模型或至少是时间序列的交叉滞后分析,而不仅仅是横断面数据的相关性系数。
从审稿人视角回头看,有几个问题几乎必问:有没有做阴性对照?有没有展示稀释曲线?Alpha多样性标准化用的抽平还是其他方法?PERMANOVA有没有考虑离散度?差异分析用的什么方法、有没有做多重比较校正?特征表是OTU还是ASV、用的什么数据库?回答清楚这些问题,文章的说服力会明显上一个台阶。我的经验是,把上述关键参数整理成一张表放进方法学部分,主动交代分析决策,远比被审稿人追问后再补要省力得多。
最后再分享一个实操习惯:每次完成一轮分析就把QIIME2的qza/qzv文件、R的sessionInfo输出和关键参数记录归档到一个带日期的文件夹。几个月后审稿意见回来要补图或调整分析时,这套存档能帮你节约一整周的时间。扩增子分析的技术栈还在快速演进,工具可以不断换,但严谨的流程管理和可复现意识,才是任何一次分析都不过时的底层能力。