3. 迁移前的资产盘点
把 Snakemake 工作流迁移到 Nextflow，最危险的做法是"边读边改"——看到一条 rule 就翻译一条，遇到报错再回头翻原文件。真正稳妥的起点是资产盘点：在动手写第一行 Nextflow 之前，先把现有工作流拆成可枚举、可分类、可标注迁移难度的清单。盘点的目标不是把 Snakefile 抄一遍，而是回答三个问题：这个工作流由哪些可独立迁移的单元构成？每个单元依赖哪些外部资源？哪些部分无法一一对应地翻译，必须重新设计？
一、盘点的六个维度
Snakemake 工作流的资产可以按六个维度切分，每个维度对应 Nextflow 中不同的落地位置：
- 规则（rule）：工作流的基本执行单元，对应 Nextflow 的 process。需要记录 rule 名称、shell/run 类型、是否 checkpoint、是否 scatter-gather（如
expand、通配符批量）。 - 配置（config）：
config.yaml、configfile:引用、命令行--config覆盖项，对应 Nextflow 的params与nextflow.config。 - 脚本（script）：
script:引用的 R/Python 脚本、notebook:、内联run:代码块，对应 Nextflow 的script/shell块或bin/目录下的可执行脚本。 - 环境（env）：
conda:、container:、envmodules:指令，对应 Nextflow 的conda、container、module指令及 profile 配置。 - 输入输出（I/O）：每条 rule 的
input/output路径、通配符命名、params中的额外参数，对应 Nextflow 的path输入输出通道。 - 动态逻辑：
checkpoint、dynamic()、lambda表达式、input中的函数调用、条件分支if/else，这是迁移中最难的部分，往往需要改写为 Nextflow 的channel操作符或nextflow.config中的动态参数。
二、从 Snakefile 提取规则清单
最直接的方式是用 Snakemake 自带的 dry-run 与 DAG 导出功能，把隐式依赖显式化。以下命令在示例工作流上执行，输出用于盘点：
# 列出所有规则及其输入输出，不实际执行
snakemake --dry-run --printshellcmds --quiet
# 导出 DAG 为 graphviz，便于观察依赖层级
snakemake --dag | dot -Tpng > dag.png
# 导出规则清单为 JSON（Snakemake 7+）
snakemake --summary > rules_summary.tsv
--summary 生成的 TSV 包含 output_file、date、rule、version、status 等列，可以直接作为盘点表的初始数据。对于 checkpoint 规则，--summary 不会展开其动态输出，需要人工标注。
三、可迁移性清单的结构
盘点结果建议落成一张可填写的表格，字段如下（示例数据来自一个假设的 RNA-seq 工作流，仅作格式演示）：
| 资产类型 | Snakemake 对象 | Nextflow 对应 | 迁移难度 | 备注 |
|---|---|---|---|---|
| 规则 | rule fastp | process FASTP | 低 | 单输入单输出，直接映射 |
| 规则 | rule star_align | process STAR_ALIGN | 低 | 需处理 genome index 路径参数 |
| 规则 | rule featurecounts | process FEATURECOUNTS | 中 | 输入为样本列表，需用 collect 通道 |
| 配置 | config.yaml: samples | params.samples + samplesheet.csv | 中 | Nextflow 推荐 samplesheet 而非 YAML 列表 |
| 脚本 | scripts/plot.R | bin/plot.R + process | 低 | 脚本本身可复用，仅改调用方式 |
| 环境 | conda: envs/star.yaml | conda 'envs/star.yaml' | 低 | YAML 文件可直接复用 |
| 动态逻辑 | checkpoint get_samples | channel.fromPath + splitCsv | 高 | 需改写为静态通道或使用 Nextflow 动态输出 |
| 动态逻辑 | lambda wildcards 条件 | filter / branch 操作符 | 高 | 需逐条分析条件语义 |
难度分级建议采用三档：低表示存在一对一映射，改写主要是语法替换；中表示需要调整数据结构或通道组织方式，但语义不变；高表示 Snakemake 的动态特性在 Nextflow 中没有直接对应，必须重新设计执行逻辑。高难度项应优先在盘点阶段标记，避免迁移中途才发现无法翻译。
四、动态逻辑的识别要点
动态逻辑是盘点中最容易被低估的部分。以下 Snakemake 构造在 Nextflow 中需要特别处理：
checkpoint：运行时才确定输出文件列表，Nextflow 中通常用channel.fromPath配合flatMap或splitCsv在流程启动前展开，或改用 Nextflow 的dynamic输出（需 Nextflow 23+）。expand()与通配符组合：对应 Nextflow 的Channel.fromPath加combine/cross，需确认笛卡尔积的维度是否一致。input中的 lambda 函数：如lambda wildcards: config["samples"][wildcards.sample]，需改写为通道映射或map操作。ruleorder与priority：Nextflow 没有直接对应，需通过通道顺序或ifEmpty控制。--config运行时覆盖：Nextflow 用params加 profile 实现，需确认哪些参数允许运行时覆盖。
五、盘点产出的交付物
一次完整的资产盘点应产出三份可直接使用的文件：
- 规则映射表：每条 rule 一行，记录 Snakemake 名称、Nextflow process 名称、输入输出通道、环境指令、迁移难度、负责人。
- 配置参数对照表：config.yaml 中的每个键，对应 Nextflow 的
params名称、默认值、是否必填、是否允许运行时覆盖。 - 高风险项清单：所有标记为"高"难度的动态逻辑，附上原始代码片段、语义说明、候选改写方案。
这三份文件不需要一次做到完美，但必须在写第一个 process 之前完成初稿。后续迁移过程中，每完成一个 process，就回填映射表的实际实现，形成可追溯的迁移记录。
六、盘点中的常见陷阱
第一，只看 rule 不看 config。很多工作流的样本列表、参考基因组路径、阈值参数都藏在 config.yaml 里，迁移时如果只翻译 rule，Nextflow 流程会因缺少参数而无法启动。盘点时必须把 config 的每个键都列出来，并确认哪些是运行时可变、哪些是固定值。
第二，忽略 --config 的运行时覆盖。Snakemake 允许在命令行用 --config key=value 覆盖配置文件中的值，Nextflow 中对应的是 params 加 profile，但覆盖优先级和默认值处理方式不同。盘点时应记录每个参数是否允许运行时覆盖，以及覆盖后的行为是否一致。
第三，把 checkpoint 当成普通 rule。checkpoint 的输出文件列表在运行时才确定，Nextflow 中无法用静态通道直接表达。盘点时必须单独标记，并评估是否可以用 splitCsv 在流程启动前展开，或者是否必须使用 Nextflow 的动态输出特性。
第四，遗漏 ruleorder 和 priority。这两个指令影响 Snakemake 在多个规则可以产生同一输出时的选择顺序，Nextflow 没有直接对应，需要在通道组织或 process 调用顺序上重新设计。盘点时应记录所有涉及规则冲突的配置。
完成资产盘点后，你手里应该有一份可执行的迁移路线图：哪些 rule 可以直接翻译，哪些需要调整通道结构，哪些必须重新设计。这份清单的质量直接决定后续迁移的返工率。下一阶段的工作，就是按照清单的优先级，从低难度项开始逐个落地。