假如测序公司交回 24 个样本的 FASTQ，你想比较处理组和对照组。打开其中一个文件，看到的是一条条测序读段。它们属于哪个基因？来自同一个基因的几种转录本，读段该算给谁？同一个样本分两条 lane 测序，最后应该占表达矩阵的几列？
nf-core/rnaseq 负责把这些读段变成有样本名、有基因名、能追查来源的表达矩阵。 这个 GitHub 仓库用 Nextflow 串联质控、比对、定量和汇总。下面以 3.28.0 版和有参考基因组的双端 bulk RNA-seq 为例，沿着一个样本走一遍。nf-core/rnaseq 仓库与版本
第一处容易出错的地方，在运行命令之前
假设供体 A 的同一文库分两条 lane 测序，供体 B 也测了一个文库。它们在样本表里可以这样写，文件名仅作示意。
sample,fastq_1,fastq_2,strandedness,seq_platform
donorA,A_L1_R1.fastq.gz,A_L1_R2.fastq.gz,auto,ILLUMINA
donorA,A_L2_R1.fastq.gz,A_L2_R2.fastq.gz,auto,ILLUMINA
donorB,B_L1_R1.fastq.gz,B_L1_R2.fastq.gz,auto,ILLUMINA
这三行最后应得到 两个样本列。重复的 donorA 告诉流程把同一样本的多次测序合并。反过来，若把所有对照组样本都命名为 control，独立生物学重复也可能被合并，后续就失去了估计组内变异的依据。逐一核对样本 ID、R1/R2 配对和供体对应关系，往往比调整比对参数更值得先做。分组、供体、批次另存为实验设计表，后面做组间比较时再按 ID 对上。官方样本表与多次测序说明
STAR 已经找到位置，为什么还需要 Salmon？
想象一个基因有长、短两种转录本，两者共享一段外显子。一条读段恰好落在共享区域，STAR 可以把它定位到基因组上的这段外显子；仅凭这条读段，仍然难以判断它来自长转录本还是短转录本。另一条读段若跨过其中一种转录本特有的剪接连接，就提供了更有区分力的证据。
在默认的 star_salmon 路线中，STAR 做剪接比对，并把比对投射到转录本坐标。Salmon 综合片段与候选转录本的相容关系，估计各转录本的丰度，再汇总到基因层级。所以 Salmon 给出的是估计计数，出现小数有其统计含义。如果两个转录本的大部分序列相同，基因总量可以相对容易估计，两种转录本各占多少却仍有较大不确定性。流程的比对与定量选项 · Salmon 方法论文
打开结果目录，先看哪几个文件？
| 手头的问题 | 打开的结果 | 怎么读 |
|---|---|---|
| 24 个样本都定量了吗？ | salmon.merged.gene_counts.tsv |
基因在行、样本在列。先把样本列名与设计表逐一匹配，再看各列的计数量级。 |
| 某个基因在这个样本里表达得多吗？ | salmon.merged.gene_tpm.tsv |
TPM 同时考虑长度和样本内总量，适合描述相对丰度。做 DESeq2 的组间检验时，应采用它支持的计数导入方式。 |
| 某个样本为何显得异常？ | MultiQC 报告、对应样本的 STAR 日志 | 查看比对、测序质量和链特异性等指标。只有一个样本异常时，优先核对该样本；整批都低时，回头查物种、参考版本和建库信息。 |
| 准备做差异表达，怎样保留定量信息？ | 各样本的 quant.sf |
一条常用途径是按同版注释建立转录本到基因的映射，用 tximport 汇总，再用 DESeq2 的 DESeqDataSetFromTximport 接入设计表。 |
一个值得追查的组合是：读段能比对上参考基因组，落入预期注释或参与定量的比例却偏低。先查 FASTA 和 GTF 是否对应同一组装、染色体命名是否一致，再看链特异性判断和文库类型。比对成功只能说明找到了相容的位置，不能保证现有注释完整覆盖那些位置。这也解释了为什么多看两份输出比盯住一个“比对率”更有意义。官方输出文件及差异表达导入说明
怎样开始，又该在哪一步停下来核对？
已经装好兼容的 Nextflow 和 Docker，并能拉取容器时，可以先运行仓库的小测试。下面固定版本，方便日后复现。
nextflow run nf-core/rnaseq -r 3.28.0 -profile test,docker --outdir results_test
小测试用来检查环境能否把流程走通。换成自己的项目，还要提供样本表、匹配的参考 FASTA 和 GTF，并用代表性完整文库确认输出。这个流程解决了上游处理口径的一致性，实验设计仍由研究者负责。如果处理组全在一批建库、对照组全在另一批，表达矩阵再整齐，也无法单凭这批数据分清处理效应和批次效应。单细胞条形码、UMI 和细胞层面的质控也需要针对相应实验设计选择流程。版本说明与测试入口
从一个样本扩大到 24 个时，再谈服务器
先拿一个数据量居中的文库和一个偏大的文库，用最终参考跑完同一路线。记录 STAR 的峰值内存、排序期间工作盘的最低剩余空间，以及从读入到定量完成用了多久。随后让多个样本同时跑，按整个批次实际完成的样本数 ÷ 经过的小时数计算吞吐量。若加并发后吞吐几乎不变，去看排序读写和任务等待；继续加线程可能只会让更多任务一起等。Nextflow 执行报告与时间线
有截止日时，先从日历里扣除上传、汇总、异常复核和交付时间，再用剩余样本数除以可用小时数。现有机器的实测速率够用，就沿用它。如果确实卡在内存、工作盘或排队时间，带着 FASTQ 总量、最大文库大小、试跑记录和截止日 去看云生信的服务器租赁配置，就能具体判断哪种资源值得增加。租用前也应把开通和搬数据的时间算进去。云生信科研服务器租赁配置与租期
