1. 课程导入与Nextflow定位

生物信息学分析很少是“一条命令跑到底”的工作。一个典型的 RNA-seq 差异表达项目，往往要经历原始数据质控、接头修剪、比对或定量、表达矩阵整理、样本分组、统计检验、富集分析、报告生成等多个阶段；每个阶段又可能包含若干工具、若干参数组合和若干中间文件。真正让流程难以维护的，并不是单个工具难用，而是这些工具之间的依赖关系、数据传递、资源需求、失败重跑和结果可追溯性交织在一起。

先看一个具体场景。假设有 24 个双端测序样本，需要完成 FastQC 质控、fastp 修剪、STAR 比对、featureCounts 定量，最后用 DESeq2 做差异分析。如果写成 Shell 脚本，常见做法是循环样本、依次调用工具，再用文件名把上下游串起来。这样做在样本少、工具固定时可行，但一旦出现以下情况就会迅速失控：某个样本比对失败需要单独重跑；服务器上同时有 8 个样本可以并行，但内存只够同时跑 2 个 STAR；换一台机器后路径和容器环境不同；半年后需要复现结果，却记不清当时用的是哪个版本的参考基因组和哪组参数。这些正是流程工程要解决的问题。

Nextflow 的设计哲学可以概括为三句话：以数据流为中心、以可复现为目标、以可移植为底线。它用 process 描述“做什么”，用 channel 描述“数据如何流动”，用 workflow 描述“阶段如何连接”。与把命令按顺序写死的脚本不同，Nextflow 更关心任务之间的依赖：某个 process 的输入来自哪些 channel，输出又流向哪里。只要依赖满足，任务就可以并行执行；某个任务失败，只影响依赖它的下游，而不必从头重跑整个项目。

这种数据流模型带来的第一个直接优势是并行与资源调度的自然表达。例如在 Nextflow 配置中，可以针对不同 process 指定资源：

process STAR_ALIGN {
    cpus 8
    memory '32 GB'
    container 'biocontainers/star:2.7.10b'
    script:
    """
    STAR --runThreadN ${task.cpus} \\
         --genomeDir ${genome_dir} \\
         --readFilesIn ${reads[0]} ${reads[1]} \\
         --outSAMtype BAM SortedByCoordinate
    """
}

这里的 cpus、memory、container 不是装饰，而是流程工程中的关键参数。它们决定了任务在本地、HPC 或云平台上如何被调度，也决定了结果能否在另一台机器上以相同方式重建。Nextflow 支持 Docker、Singularity、Conda 等环境封装方式，使“在我机器上能跑”不再依赖口头约定。

第二个优势是可复现与可追溯。Nextflow 会为每次运行生成唯一的 work 目录，记录输入、输出、命令、环境、退出状态和日志。配合 -resume，已经成功完成且输入未变化的任务会被缓存复用，只重跑失败或受影响的环节。对于动辄数小时的比对和定量任务，这能显著节省时间。对于需要审计的分析项目，这种“每个中间结果都能追溯到具体命令和参数”的能力，比最终结果本身更有价值。

第三个优势是可移植与可扩展。同一份 main.nf 可以在笔记本上用本地执行器跑小样本测试，也可以提交到 Slurm、SGE、PBS 集群，或迁移到 AWS Batch、Google Cloud 等云平台。执行环境的差异通过配置文件隔离，流程逻辑本身不需要重写。这种“逻辑与执行分离”的结构，使流程从一次性脚本逐步演化为团队可维护的资产。

为了更直观地理解 Nextflow 与传统脚本的差异，可以用下面的关系图对比两者的数据流组织方式。左侧是脚本式“按顺序执行”的线性结构，右侧是 Nextflow 的“依赖驱动”结构：样本 channel 同时进入多个 process，各 process 的输出再汇入下游，失败任务只阻断其下游分支。

从图中可以看到，Nextflow 并不是简单地把脚本“包装”起来，而是把样本、任务、资源、依赖和缓存都变成了可管理的对象。对于生物信息流程工程而言，这种结构带来的直接收益是：并行度由数据决定，资源由 process 声明，失败由依赖隔离，复现由缓存和容器保障。

Nextflow 的典型应用场景也因此非常明确。第一类是多样本批量分析，如 RNA-seq、WGS/WES、ChIP-seq、宏基因组等，样本数量从几十到上千，天然适合并行。第二类是多工具组合流程，如 nf-core 社区中已经沉淀的 rnaseq、sarek、atacseq、ampliseq 等流程，直接复用成熟的最佳实践。第三类是跨平台部署，同一流程在本地测试、集群生产、云端弹性扩容之间切换。第四类是需要审计和复现的项目，例如临床研究、合作课题或需要长期维护的实验室流程。

需要强调的是，Nextflow 不是“更快的 Shell”，也不是“必须上云才能用”的重型框架。它的核心价值在于把流程从“一次性命令集合”提升为“可描述、可调度、可复现、可移植的工程对象”。学习 Nextflow，本质上是在学习如何用数据流的方式思考生物信息分析：先明确输入输出，再定义任务边界，最后配置执行环境。后续章节会逐步展开 process、channel、workflow、配置、容器、缓存、错误处理和部署等具体机制。本节只需要建立一个判断：当分析任务开始出现多阶段、多样本、多环境或复现需求时，就是引入 Nextflow 的合适时机。