参数基础：如何定义参数
说实话，我刚接触 Nextflow 那会儿，对参数这块儿也是一头雾水。params.xxx 到处都有，但到底它和 def 定义的变量有啥区别？我当时花了整整一个下午才真正搞明白。这一章，我就把参数定义这件事儿给你讲透。
3.1 认识 params 作用域
在 Nextflow 里，所有可被用户配置的入口，都统一收在 params 这个 Map 下面。说白了，它就是一个全局配置桶——你往里面放什么，外部就能通过命令行或者配置文件改什么。
核心规则：参数必须在 workflow 块 之外 定义，才能被外部识别和覆盖。
举个例子，你可以在 main.nf 开头这样写：
params.input_fastq = "$projectDir/data/sample.fastq"
params.genome_index = "$projectDir/genome/GRCh38"
params.outdir = "./results"然后整个流程里，任意 process 都可以直接用 params.input_fastq 拿到这个值。我在项目中遇到过有人把参数定义写在 workflow{} 里面，结果命令行传参死活不生效——嗯，位置错了。
3.2 默认参数设置
为什么一定要设默认值？你想想看，如果没有默认值，用户每次运行都得敲一堆 --param，少一个就报错。这种体验太糟糕了。
我个人的习惯是：所有参数都给出合理的默认值，让用户拿到脚本就能直接跑起来，再按需覆盖。
// 默认参数集中定义在 workflow 块之前
params.input_fastq = "$projectDir/data/sample.fastq"
params.outdir = "./results"
params.genome = "GRCh38"
params.max_memory = "16.GB"
params.max_cpus = 4
params.keep_intermediate = false技巧：默认值尽量用 $projectDir 这类动态路径，别写死绝对路径。这样别人克隆你的仓库后，不需要改代码就能跑。
参数设好默认值后，用户在命令行里只需要改自己关心的部分：
nextflow run main.nf --input_fastq "./my_data/hello.fastq" --max_cpus 8没传的参数直接用默认值，方便又安全。
3.3 参数命名规范
命名这件事，看着小，坑却不少。我曾经在一个项目里看到有人用 params.INPUT、params.input、params.in 三个名字指代同一个东西——维护起来简直灾难。
Nextflow 社区有一套约定俗成的规则，我整理成了一张表：
| 推荐命名 | 不推荐命名 | 说明 |
|---|---|---|
params.input_fastq |
params.INPUT |
全小写 + 下划线，不用大写 |
params.genome_index |
params.idx |
全名清晰，不要用模糊缩写 |
params.max_cpus |
params.max |
具体不泛化，避免歧义 |
params.reference.genome |
params.ref_genome |
点号表示层级结构，推荐 |
params.tools.bwa.index |
params.bwa_idx |
按工具/模块分层组织 |
几条硬规则记牢：
- 全小写，单词之间用
_分隔 - 不要用驼峰（
params.inputFastq）——容易和 Groovy 变量风格混淆 - 善用点号分层，比如
params.tools.bwa.threads比params.bwa_threads更好扩展 - 不要缩写到看不懂，
params.idx不如params.bwa_index直接
3.4 参数与变量的核心区别
这是初学者最容易踩的坑。我刚开始用 Nextflow 时，就因为在 process 里用 def 定义了一个和参数同名的变量，结果命令行传参死活覆盖不了——查了半天才发现变量把参数给"屏蔽"了。
参数和变量，本质上是两类东西：
| 维度 | 参数 (params) | 变量 (def) |
|---|---|---|
| 定义方式 | params.xxx = value |
def xxx = value 或 xxx = value |
| 作用域 | 全局可见，所有 process 和 workflow 都能访问 | 局部可见，只在定义它的块内有效 |
| 可被外部覆盖 | 是，通过 --xxx value 或配置文件 |
否，编译时已固定 |
| 生命周期 | 从流程启动到结束，全程不变 | 随作用域创建和销毁 |
| 典型用途 | 配置入口（输入文件、参数阈值、开关） | 内部数据（计数器、临时计算结果） |
| 类型约束 | 宽松，运行时按需解析 | 相对严格，遵循 Groovy 类型规则 |
避坑指南：千万不要在 workflow{} 或 process 内部用 def 定义一个与已有参数同名的变量——它会"遮蔽"参数，导致外部传参失效。我曾经帮同事调试过一个跑了两周没发现参数没生效的案例，原因就是这个。
简单来说：参数是给用户看的接口，变量是给自己用的工具。你设计流程时，先想清楚哪些值需要让用户调整，把它们做成参数；剩下的内部逻辑，用变量就够了。
往大了说，参数就是工作流与外部世界的"契约"——你定义好参数，用户按契约传值，流程按契约执行。把契约设计清晰了，后面的维护成本能降一大截。
看到这张图，你应该能直观感受到：参数从外部进入，经过 params 统一收口，再被流程引用——整个过程清晰、单向、可追踪。这就是我推荐的设计思路。