核心概念：进程、通道、工作流

开篇我先说句实在话——理解这三个概念，等于拿到了Nextflow的钥匙。进程、通道、工作流，说白了就是Nextflow世界里的「工人」「传送带」和「工厂图纸」。我刚开始接触时总觉得它们彼此分离，直到在一次大规模RNA-seq流程重构中才真正悟透：没有通道，进程就是孤岛；没有工作流，通道就是乱麻。

嗯，咱们一个一个来拆。

进程：Pipeline的最小执行单元

进程就是你的运算步骤。在Nextflow里，每个process都对应一个独立的任务，可以跑在本地、集群或者云端。我习惯把进程想象成带输入输出接口的黑箱——你给它数据，它执行命令，然后吐出新数据。

一个最简单的进程长这样：

process align_reads {
    input:
    path reads

    output:
    path "aligned.bam"

    script:
    """
    bwa mem reference.fa $reads | samtools sort -o aligned.bam
    """
}

注意几个关键点：input和output声明了进程的「门」；script块里写的是实际执行的命令。我在项目中见过不少新人把路径写死在里面，结果换环境就崩——记住，输入输出一定要通过通道传递，不要硬编码路径。

通道：数据流动的血管

通道就是数据的管道。它把上一步进程的输出，送到下一步进程的输入。你想想看，没有通道，进程就像一台台独立运转的机器，没人能把它们串起来。

通道有几个常见的创建方式：

• Channel.fromPath()：从文件路径列表创建通道
• Channel.fromList()：从内存列表创建通道
• Channel.empty()：创建一个空通道（常用于分支汇聚）

举个例子：

// 从FastQ文件创建通道
raw_fastq = Channel.fromPath("/data/raw/*.fastq.gz")

// 处理
process trim_galore {
    input:
    path fastq

    output:
    path "trimmed_${fastq}"

    script:
    """
    trim_galore $fastq
    """
}

这里raw_fastq通道把文件路径喂给trim_galore进程，进程处理完后又通过output生成新通道。我曾经犯过一个低级错误——在output声明里忘记写path修饰符，结果下游进程死活拿不到文件。调试了半小时，最后发现就是少了一个path。

工作流：把一切串起来

工作流就是定义进程之间如何连接的脚本。在Nextflow里，工作流通常写在workflow {}块里。我见过一些老派做法把所有进程和通道混在一起写，可读性极差。后来我强制自己把所有进程定义放在process块里，工作流只做「连线」的事，你的同事会感谢你。

一个完整的工作流示例：

nextflow.enable.dsl=2

params.reads = "/data/raw/*.fastq.gz"
params.reference = "/refs/hg38.fa"

workflow {
    // 1. 创建输入通道
    reads_ch = Channel.fromPath(params.reads)
                .map { file -> file.name }
                .set { raw_fastq }

    // 2. 质控
    fastqc(raw_fastq)
    // 3. 比对
    align_reads(raw_fastq, Channel.value(params.reference))
    // 4. 排序 + 索引
    sort_bam(align_reads.out.bam)
    // 5. 变异检测
    call_variants(sort_bam.out.sorted_bam)
}

process fastqc {
    input:
    path fastq

    output:
    path "${fastq.baseName}_fastqc.*"

    script:
    """
    fastqc $fastq
    """
}

// 其他进程定义省略...

这里工作流里fastqc(raw_fastq)的意思就是：把raw_fastq通道传给fastqc进程的input。进程fastqc的output会自动生成新通道，下游进程可以直接引用。

三者关系：一张图看懂

我画了一张流程图帮你理解它们如何协作：

从图中你能看到：

• 源通道：从外部文件系统创建，不依赖任何进程
• 中间通道：由进程的output自动生成，可被下游任意进程消费
• 汇聚通道：多个输入合并成一个，常用于合并不同步骤的结果
• 结果文件：最终产出，可以写回磁盘或导出

DSL2 模式下的变化

Nextflow DSL2 引入了一个重要的变化：进程之间不再通过全局通道名硬编码连接，而是通过take和emit显式声明输入输出。我个人非常喜欢这个设计，因为大型项目中你不再需要回溯整个文件去找通道定义在哪里。

DSL2 写法示例：

process fastqc {
    input:
    path fastq

    output:
    path "${fastq.baseName}_fastqc.*"

    script:
    """
    fastqc $fastq
    """
}

workflow {
    // 注意这里直接引用进程，而不是通道名
    fastqc(Channel.fromPath("*.fastq.gz"))
    // fastqc.out 自动携带输出
}

常见陷阱与我的血泪史

最后再分享三个我亲自踩过的坑：

1. 通道只被消费一次：一个通道默认只能被一个进程消费。如果你想复用（比如比对和质控都需要同一份fastq），必须用.branch()或.multiply()创建副本。
2. 通道中的元素顺序：通道是无序的！如果下游进程依赖特定顺序，一定要在输入时显式.sort()或使用groupTuple配对。
3. 输出路径冲突：如果两个进程输出相同文件名，Nextflow会报错或覆盖。我曾经在合并多个样本的质控报告时，因为所有fastqc结果都叫fastqc_report.html导致互相覆盖，最终使用publishDir的pattern才解决。

这三个概念像是三根支柱，撑起整个Nextflow的运作。你理解了它们之间的数据流向，就能组合出任意复杂的流程。嗯，这个基础打牢了，后面讲版本回溯和质控时就更有底气了。