第2章 字符串参数：传递文本字符串，处理引号与转义字符

字符串参数在 Nextflow 里看着简单，但坑其实不少。我刚开始用的时候，一个带空格的文件路径折腾了我一下午。你想想看，一个参数传进去，要么被 Shell 拆成两半，要么引号没处理好直接报错。这一章我们就专门聊聊怎么安全、正确地传递字符串参数。

2.1 字符串参数的基本传递方式

在 Nextflow 里，字符串参数最常见的来源有三个：params 定义、命令行传参、配置文件。我们逐个看。

2.1.1 通过 params 定义

直接在 nextflow.config 或脚本里写：

params.input = "/data/sample.fastq"
params.outdir = "./results"

然后在脚本里用 params.input 引用。这种写法最安全，因为 Nextflow 内部会处理好字符串的转义和类型。但要注意：如果路径里包含空格，你仍然需要加引号吗？一般来说，params 定义的值会被当作字符串字面量，不需要额外加引号。不过有个例外——当你在命令行里覆盖时，引号的问题就来了。

2.1.2 命令行传参

最常见的场景：

nextflow run main.nf --input "/path with space/sample.fastq"

这时候 Shell 会先解析整条命令。如果参数值里有空格，你必须用双引号或单引号把整个值包起来。不然 --input 后面只认到空格前的部分。我个人习惯统一用双引号，因为双引号里还能解析变量和转义符，而单引号会把所有内容当纯文本。

2.1.3 通过配置文件

用 YAML 或 JSON 配置文件时：

params {
  input = '/path/to/data'
  label = 'RNA-seq'
}

这里单引号、双引号都可以，但注意 Groovy 语法里单引号是字符串，双引号支持插值。我在项目中遇到过一个坑：在 YAML 配置里写了双引号，里面的 $ 符号被当作 Groovy 变量解析了，结果传进来的值完全不对。所以如果你不需要变量插值，建议用单引号。

2.2 引号与转义字符详解

字符串参数最让人头疼的就是引号和转义。我们拆开讲。

2.2.1 引号的三种层次

• Shell 层的引号：你敲命令时，Shell 会先处理一层引号。比如 --param "some value"，Shell 会把 "some value" 作为一个整体传给 Nextflow。
• Groovy/Nextflow 层的引号：Nextflow 收到参数后，会再按 Groovy 语法解析字符串。如果你的参数值里本身包含引号，就需要转义。
• 应用层的引号：如果你的流程里把参数传递给外部工具（比如 samtools view），那个工具也可能需要自己的引号处理。

我记得有一次，我要传一个包含逗号的样本列表：sample1,sample2。在命令行里写 --samples "sample1,sample2" 没问题，但如果我的样本名本身带了引号字符，比如 sample"1，那就要小心了。

2.2.2 转义字符

在双引号字符串里，你需要转义的特殊字符包括：\n（换行）、\t（制表符）、\\（反斜杠本身）、\"（双引号）、\$（美元符号）。单引号字符串里只有 \\ 需要转义，其他都是字面量。

实战中，我经常在传递正则表达式时遇到转义问题。比如：

params.pattern = "SRR\\d{6}"

这里的 \\d 需要双反斜杠，因为 Groovy 字符串里 \d 会被当作转义序列 \d（不是数字匹配）。如果你在命令行里写：

--pattern "SRR\\d{6}"

那 Shell 还会再吃掉一层反斜杠，最终传到 Nextflow 的字符串只剩下 SRR\d{6}。怎么解决？要么在命令行里写四层反斜杠 \\\\，要么直接把正则表达式放到 nextflow.config 文件里，避免 Shell 干涉。

2.3 常见陷阱与避坑指南

• 路径中的空格：永远用引号包起来。我见过有人用反斜杠转义空格 path\ with\ space，但不同的 Shell 表现不一样，不如引号统一。
• Windows 路径中的反斜杠：Nextflow 基于 JVM，反斜杠在 Java 字符串里是转义符，所以 Windows 路径 C:\Users\data 必须写成 C:\\Users\\data 或使用正斜杠 C:/Users/data。我个人强烈建议把所有路径统一为正斜杠，Nextflow 和大多数工具都能识别。
• 密码或特殊符号：像 $、!、# 这些字符在 Shell 里有特殊含义。传递密码等敏感信息时，优先用环境变量或 params 定义，避免在命令行暴露。
• 引号嵌套：比如你要传一个 JSON 字符串给某个工具：--json '{"key":"value"}'。在命令行里用单引号把整个 JSON 包起来，内部的双引号就不需要转义。如果非要用双引号包，里面每个双引号都要转义 --json "{\"key\":\"value\"}"，非常容易出错。

2.4 实战：一个安全的字符串参数传递模板

下面是我自己在项目里总结的推荐做法。假设我们要传递一个样本名称、一个输入文件路径和一个正则表达式匹配模式。

配置文件 nextflow.config

params {
  sampleName = 'HCC-001'
  inputFile  = '/data/HCC-001/raw.fastq.gz'
  pattern    = 'HCC-\\d{3}'
}

在主脚本 main.nf 中引用

process fastqc {
  input:
  path fastq from params.inputFile
  
  script:
  """
  fastqc -o results "$fastq"
  """
}

workflow {
  fastqc()
  log.info "Processing sample: ${params.sampleName}"
  log.info "Looking for pattern: ${params.pattern}"
}

命令行运行

如果你想临时覆盖某个参数：

nextflow run main.nf --sampleName 'HCC-002' --pattern 'HCC-\\d{3}'

注意：这里 --pattern 的值在命令行里用了单引号，Shell 不会解析内部的反斜杠和 \d，直接原样传给 Nextflow。Nextflow 的 Groovy 解析器再处理一次，变成 HCC-\d{3}，刚好是我们想要的正则。

如果你非要用双引号，那就得写四层反斜杠 "HCC-\\\\d{3}"，极易出错。所以我建议：配置文件里用单引号，命令行里也用单引号，这样转义问题最少。

2.5 字符串参数传递的总览

为了让整个流程更直观，我画了张图，展示字符串参数从源头到最终使用的路径：

从上图可以看清楚，一个字符串参数从源头到工作流，至少要经过三层解析：Shell 引导、Nextflow 的 Groovy 解析、最终工具的解析。每一层都可能改变字符串的内容。理解这个流程，你就知道什么时候该加引号、什么时候该转义了。

2.6 小结

字符串参数传递的核心就是两个词：引号和转义。记住几条原则：

• 能用配置文件就别用命令行传复杂字符串。
• 命令行里统一用单引号包住参数值。
• 路径用正斜杠，避免反斜杠转义问题。
• 不确定时打印日志看看实际值。