GNU Parallel输入源完全指南：stdin、-a、::: 与组合策略

大家应该在不少脚本里见过 xargs -P，但要论把“一堆参数”变成“一堆并行任务”这件事做得最通透的，还得是 GNU Parallel。GNU Parallel 的模型很直接：你给它一个输入源（Input source），它把输入源里的每一行（或每个字段）变成一条命令的参数，然后同时跑起来。可很多同学用着用着就卡在“输入源”这一步，搞不清 stdin、-a、::: 到底啥区别，于是命令要么参数全串了，要么干脆不并行。这篇文章专门聊聊输入源这部分，是我在脚本里反复折腾之后的整理，适合已经把 parallel 基础命令跑通、但想更准确控制参数来源的人。

1. 输入源的核心逻辑：先把“参数从哪来”想清楚

1.1 输入源的本质：任务的拆分依据

GNU Parallel 和普通命令执行方式最大的区别，不是“能并行”，而是“怎么拆分任务”。一条命令一次只能处理一组参数，并行则是把一批参数按行拆开，每一行送给一个独立的命令进程。输入源干的事，就是把“这一批参数”准备好，并按行切开递给并行命令。

所以我把输入源理解成一条流水线的传送带：传送带上的每一个“格子”就是一行参数，格子里的内容被塞进命令的占位符里，命令就拿到了一份活儿。这个比喻看着简单，但能帮你在设计脚本时少走很多弯路——你不需要先想“怎么写并行命令”，而是应该先想“输入源怎么组织，才能让每条命令拿到的参数是完整且明确的”。

1.2 三种输入源与适用场景

GNU Parallel 的输入源归结起来就三类，使用上既有重叠又有各自擅长的场景：

这三类方式可以混合使用，甚至可以同时出现多个输入源，做多参数组合。第4章的重点就是把这些组合方式和它们背后的规则理清，不然看官方文档容易晕。

2. 三种输入源实操：从管道到文件到内嵌参数

2.1 标准输入：最顺手但也最容易忽略细节

GNU Parallel 默认从标准输入读取数据，一行一个参数，这也是最常用的方式。比如批量对一堆数字做处理：

bash复制seq 1 100 | parallel echo "数字是 {}"

这里 {} 是占位符，代表输入源传进来的参数。seq 输出 1 到 100 共 100 行，parallel 就启动 100 个 echo 任务并行执行。你可以用 -j 参数控制同时跑几个，默认是 CPU 核心数，对于简单命令可能看不出差别，但一旦命令里是压缩、转换、网络请求这类耗时操作，并行和串行的差距是数量级的。

标准输入模式下有个细节容易被忽略：默认分隔符是换行，如果输入里有空格，一行内容会被整体当成一个参数吗？答案是会。GNU Parallel 是按行读的，空格不会把一行拆成多个参数。但如果你的数据用的是其他分隔符，比如逗号或制表符，你希望一行里的多个字段各进各的占位符，那就得配合 --colsep 参数，后面我会单独讲。

如果你想每次读入两行合并成一个任务，用 -N2：

bash复制cat pairs.txt | parallel -N2 echo "第一个是 {1}，第二个是 {2}"

-N 参数控制“每执行一次命令，从输入源里取几行”，取到的多行分别放到 {1}、{2} 等占位符里。这在处理成对数据时非常实用，比如一个文件里每两行是一组配置，上面是主机名，下面是IP。

2.2 用 -a 指定文件输入：稳定且可复用

标准输入虽然方便，但有一个天然的冲突：如果命令本身还需要读标准输入，管道和命令的标准输入就会打架。这时候用 -a 指定文件更稳。

bash复制parallel -a /tmp/file_list.txt ls -lh {}

-a 后面跟文件名，每行一个参数，效果等价于：

bash复制cat /tmp/file_list.txt | parallel ls -lh {}

但 -a 的好处是：你可以在同一台机器上反复运行同一个命令，不必每次重新生成管道数据，也方便在脚本里做日志排查。配合多个 -a 参数，相当于多个输入源，GNU Parallel 会给它们做笛卡尔积组合：

bash复制parallel -a hosts.txt -a commands.txt ssh {1} '{2}'

这会把 hosts.txt 里的每个主机和 commands.txt 里的每条命令一一配对，组合数等于两个文件行数的乘积。这个功能看着简单，用好了能快速扩展批量运维任务，但也因为组合是笛卡尔积，文件行数多了以后任务数会爆炸式增长，使用前最好估算一下总量。

2.3 ::: 和 :::: 内嵌参数：临时测试神器

::: 是三组输入源里最“GNU Parallel 特色”的写法，它允许你直接在命令行里写参数，不必借助文件或管道：

bash复制parallel echo {} ::: A B C

输出是 A、B、C 三行。快速测试一个命令的参数组合时特别方便，比如我想看看某个脚本在不同参数下的效果，一行命令就搞定：

bash复制parallel python3 my_script.py --mode {} ::: train test eval

:::: 则是从文件读取的等价写法，效果与 -a 一样：

bash复制parallel echo {} :::: config_list.txt

注意 ::: 和 :::: 之间看似只差一个小点，但一个是参数，一个是文件名，写混了会出现奇怪报错。比如你写了 :::: config_list.txt，但实际文件不存在，GNU Parallel 会直接把 "config_list.txt" 当成一个字面参数去执行，不会报“文件不存在”，这是不少人踩过的坑。

还有一个在命令行使用 ::: 时的常见问题：shell 的路径展开。如果你写：

bash复制parallel echo {} ::: *.log

shell 在把参数交给 parallel 之前，就已经把 *.log 展开成当前目录下所有 .log 文件名了。这通常没问题，但如果你是想把 *.log 这个字符串原样传给后续命令，就必须加引号：

bash复制parallel echo {} ::: '*.log'

加了引号之后，parallel 拿到的参数就是字面量 *.log，至于后续命令怎么处理这个字符串，取决于命令本身。这个细节不算 GNU Parallel 的问题，而是 shell 参数展开顺序的问题，但实际使用中非常容易困惑，建议先把这点刻在脑子里。

3. 多输入源的组合策略：笛卡尔积、按行对齐与参数引用

3.1 默认的笛卡尔积组合

当你在一条 parallel 命令里同时使用多个输入源，GNU Parallel 默认的行为是做笛卡尔积。所谓笛卡尔积，就是每个输入源里的每一个元素，都要和其他输入源里的每一个元素配对一次。

bash复制parallel echo {1}-{2} ::: A B C ::: 1 2 3

这条命令会输出 3×3=9 行：A-1、A-2、A-3、B-1、B-2、B-3、C-1、C-2、C-3。两个输入源分别对应占位符 {1} 和 {2}。这个能力的价值在于生成“测试矩阵”，比如你想交叉验证三种模型和三个数据集：

bash复制parallel python3 train.py --model {1} --dataset {2} ::: cnn lstm attn ::: data1 data2 data3

一条命令就把 9 个任务全部跑上，还可以加 -j 控制同时跑几个。注意这种写法下，{1} 只代表第一个输入源，{} 则代表当前这一行里的全部参数（A-1 这样的组合整体）。多个输入源时，我建议明确写 {1}、{2}，因为你没法保证 {} 展开后的格式正好是后续命令想要的。

3.2 --xapply 按行对齐：不希望穷举时怎么办

笛卡尔积虽然强大，但有些场景下你并不想让参数两两组合，而是要让两个输入源“按行一一对应”。比如 file1.txt 里是主机名，file2.txt 里是对应主机的端口，第一行对第一行，第二行对第二行，这时用 --xapply 更合适：

bash复制parallel --xapply ssh {1} -p {2} 'uptime' :::: hosts.txt :::: ports.txt

--xapply 会让多个输入源按行对齐组合，hosts.txt 的第一行搭配 ports.txt 的第一行，两个输入源各 10 行就产生 10 个任务，而不是 100 个。如果某个输入源行数不够，GNU Parallel 会用空字符串补齐剩余位置，这个行为在数据结构不齐时要注意，最好提前用 wc -l 确认一下行数一致。

这里的 :::: hosts.txt :::: ports.txt 和 -a hosts.txt -a ports.txt 在效果上是等价的，写哪种纯看个人习惯。我自己在脚本里更倾向用 -a，因为它更显眼，别人读代码时一眼就能看出“这里是文件输入”。

3.3 串行拼接输入源：::: 加号变体

除了默认的笛卡尔积和 --xapply 按行对齐，GNU Parallel 还提供了 :::+ 和 ::::+ 这两种串联输入源。它们的作用是“当多个输入源同时出现时，不再做组合，而是按顺序逐个串成一个输入流”。这个功能用到的频率不高，但某些场景下非常巧妙。

bash复制parallel echo {} :::+ A B C :::+ 1 2 3

这条命令会输出 A、B、C、1、2、3 六行，和笛卡尔积完全相反。你可以把它理解成把多个参数列表首尾相接拼成一个列表。这种写法在做“参数总量很大，拆成多个文件逐个喂给命令”时有用，不过第4章阶段了解即可，平时用不上太频繁。

3.4 按列拆分输入行：--colsep 的妙处

前面提到过，GNU Parallel 默认按行读取输入源，一行整体作为一个参数。但如果你手里的数据本身就是表格，一行里有多个字段，比如 CSV、TSV 格式，直接用默认方式会很难处理。这时用 --colsep 指定列分隔符，GNU Parallel 会自动把每一行拆成多列，并分别放进 {1}、{2}、{3} 等占位符。

bash复制printf 'A,10\nB,20\n' | parallel --colsep ',' echo "name={1} value={2}"

输出：

code复制name=A value=10
name=B value=20

输入文件里每行两列，分别对应 {1} 和 {2}，不用再在命令里手动割字符串。这个功能在处理性能测试结果、日志统计、批量配置数据时非常实用。比如我有一个 Nginx 访问日志文件，格式是“IP 时间 请求路径 状态码”，想批量统计每个 IP 的请求次数，就可以把日志按空格拆列后让 parallel 分组处理。不过要注意，--colsep 必须和输入源的解析配合，如果你同时用了多个输入源，它只对每个输入源的每一行做拆分，多个输入源之间仍然是按前面的组合规则处理。

4. 实战：完整跑通一个多输入源任务

4.1 需求场景：批量压缩并归档图片

假设一个目录下有几千张图片，你要把它们逐张压缩并转成统一尺寸，最后归档到另一个目录。串行处理可能要好几分钟，用 GNU Parallel 可以压到秒级。输入源选择标准的文件列表：

bash复制find ./images -type f -name "*.jpg" -print0 | parallel -0 convert {} -resize 800x600 ./processed/{/.}.png

这里两个细节值得说明：-print0 和 -0 配对使用，让文件名用 null 字符分隔，避免文件名里有空格或特殊字符时被错切分；{/.} 是 GNU Parallel 的替换字符串，表示“去掉目录路径并去掉扩展名”，这样输出的新文件名正好是你想要的样子。

当然，convert 命令本身是 ImageMagick 的命令，你完全可以根据自己的工具替换。关键是理解：find 构造了输入源，-0 告诉 parallel 输入源的分隔方式，{} 和 {/.} 决定参数怎么进入具体命令。

4.2 需求场景：按行对应的配置读取

再来看一个需要 --xapply 的实战场景。假设你有两个文件，一个保存主机名，一个保存对应端口，行数相同，你想逐台执行健康检查：

bash复制# hosts.txt
web01
web02
web03

# ports.txt
8080
9090
7070

bash复制parallel --xapply -a hosts.txt -a ports.txt curl -s http://{1}:{2}/healthz

这样会依次请求 web01:8080、web02:9090、web03:7070，而不会把 9 种组合全跑一遍。如果我用默认的笛卡尔积，就变成了 9 个请求，其中大部分是无意义的组合。所以 --xapply 在处理“结构化数据”时不是可选优化，而是必需手段。

4.3 调试技巧：--dry-run 先看清命令再执行

并行命令最怕的是“跑得飞快但全跑错了”，因为任务数量一多，肉眼很难在实时输出里发现问题。我的习惯是每次写复杂输入源时，先用 --dry-run 把命令打印一遍，不实际执行：

bash复制parallel --dry-run --xapply -a hosts.txt -a ports.txt curl -s http://{1}:{2}/healthz

输出会显示每条将要执行的完整命令。这个动作 5 秒钟就能做完，能帮你拦截掉大部分输入源配置错误。尤其当你用了三四个输入源，还混合了 ::: 和 -a 时，--dry-run 几乎是必需步骤。真正执行时如果还想保留记录，可以把输出重定向到日志文件：

bash复制parallel --joblog run.log --xapply -a hosts.txt -a ports.txt curl -s http://{1}:{2}/healthz

--joblog 会生成一个任务日志，包含每个任务的状态、退出码和耗时。这是排查并行任务“哪个失败了、为什么失败”的最好工具，比盯着滚动输出靠谱得多。我处理批量任务时，几乎默认加上 --joblog，尤其是任务数量上百时，后期分析处理结果全靠这张表。后续章节应该会系统讲参数替换和任务日志，但这里提前用上能让你少踩很多坑。

5. 常见问题与排查实录

5.1 命令里自带花括号导致参数替换错乱

GNU Parallel 的一大特点是 {} 作为占位符。但如果你要执行的命令本身就包含花括号，比如 awk '{print $1}'，麻烦就来了，parallel 会把 awk 命令里的 {print $1} 也当成占位符替换掉，最终生成一堆残缺命令。

一个典型的错误示例：

bash复制parallel awk '{print $1}' {} ::: a.txt b.txt

这会让 GNU Parallel 把 {print $1} 里的内容误解为参数替换的一部分，命令结构直接被破坏。正确做法是对花括号转义，或者把整条命令放进单引号里再转义内部引号：

bash复制parallel "awk '{print \$1}' {}" ::: a.txt b.txt

这里的 $ 是为了让 shell 不把 $1 展开成 shell 变量，单引号嵌套通过转义实现。这类问题很隐蔽，因为你看到报错时往往一头雾水。我的排查经验是：只要命令里出现 awk、sed、perl 这类自带花括号或 $ 符号的工具，先跑 --dry-run，看生成后的命令是否还完整，这样立刻就能发现是不是占位符被误替换了。

5.2 文件名含空格导致参数被拆碎

输入源里的每一行默认是一个整体参数，不会因为空格被拆分。但在某些场景下，空格问题依然会出现，最常见的反而是 find 命令的输出配合管道时。比如：

bash复制find . -name "*.jpg" | parallel convert {} {.}.png

如果文件名是 "my photo.jpg"，GNU Parallel 按行读取，仍然会把 "my photo.jpg" 当成一个整体参数，不会拆成 "my" 和 "photo.jpg"。真正有风险的情况是文件名里本身包含换行符——这在现实里极少见，但确实存在。

更常见的坑是输入源文件里每一行包含多个字段，比如 "my photo.jpg output.png" 这种格式。GNU Parallel 默认按行取，不会自动拆列，所以如果你期望空格分隔成两个参数，需要显式指定分隔符：

bash复制cat filelist.txt | parallel --colsep ' ' convert {1} {2}

如果你要处理的文件名集合来自 find，最稳妥的方式还是用 -print0 + parallel -0 的组合，null 分隔符可以避免几乎所有特殊字符问题。

5.3 多个输入源混杂使用时占位符混乱

我见过不少朋友写出这样的命令：

bash复制parallel echo {} ::: A B ::: 1 2

结果发现输出的顺序和自己预期不一样，或者根本分不清哪个参数对应哪个输入源。前面说过，{} 在多输入源时代表“全部参数的组合”，它的具体格式可能随版本和上下文而变化，非常不适合作为精确控制的手段。

更清晰的做法永远是显式使用 {1}、{2}。这样不管输入源怎么组合，你都知道 {1} 来自第一个输入源，{2} 来自第二个输入源。这套命名规则在 GNU Parallel 全系列里是统一的，养成写 {1} {2} 的习惯后，脚本可读性会上一个台阶。

5.4 输入源为空时命令直接不执行还是报错

如果输入源完全为空，比如管道上游一条输出都没有，GNU Parallel 会直接退出，不执行任何任务。这个行为一般符合直觉，但有些情况下你希望即使没有输入，也执行一次带空参数的命令，那就得另外处理。

另外要注意的是，GNU Parallel 默认会读取每一行，包括空行。输入列表里的空行会被当成空参数执行一次，这往往不是你想要的结果。提前用 grep -v '^$' 过滤空行，或者用其他方式预处理输入源，是更安全的做法。

bash复制grep -v '^$' list.txt | parallel echo "处理: {}"

5.5 任务数量远超核心数时会不会把内存撑爆

还有一个常被问到的问题：如果输入源有 10 万行，GNU Parallel 是不是会一次性把 10 万个参数都加载到内存里？答案是并不会。GNU Parallel 是流式读取输入源的，它读一行、执行一个任务，同时只维护正在运行的任务队列。因此输入源行数再多，内存增长也是有限的。

这一点和第4章输入源的设计有关：因为输入是可流式读取的，你完全不用为了“总行数太多”而担心内存溢出。想想你以前用 xargs 处理超大文件时还要小心翼翼分块，GNU Parallel 省了这一步，直接把输入流喂进去就行。

6. 输入源选择的一些经验性建议

6.1 小批量测试用 :::，正式脚本用文件

::: 的最大优势是快，不用建临时文件就能把一组参数丢进去。但正因为它写在命令行里，如果参数数量多、或者参数里有特殊字符，整条命令会变得很难维护。我的习惯是：临时 10 个以内的参数用 :::，超过 10 个或需要反复调整的，一律写进文件，再用 -a 或 :::: 读取。这样改参数不需要动命令本身，也方便版本管理。

6.2 输入源文件的编码和换行符要统一

这个问题在 Linux 下不常见，但如果你把在 Windows 编辑过的文件直接当输入源用，行尾的 \r 会混进参数里，命令执行时大概率报错“命令未找到”或“文件不存在”。遇到这种诡异问题，先检查一下输入源文件的换行符：

bash复制file list.txt

如果发现 CRLF 行尾，用 dos2unix 转一下再喂给 parallel 就好。这类问题说起来很小，但排查起来相当费时间，尤其是任务量一大，你不会马上意识到是输入源的格式问题而不是命令本身的问题。

6.3 输入源命名讲究一点，下游少踩坑

如果你用 ::: 直接写文件列表，输入源里最好只放“数据本身”，不要混入多余说明。比如有人喜欢在文件里写注释行，以 # 开头，但 GNU Parallel 并不会自动忽略这些行，它们会被当成真实参数传给命令。给你的输入源文件加注释不是不行，但要在上游就过滤干净再交给 parallel，别等着 parallel 帮你识别。

我在实际项目里会把输入源文件单独放在一个 inputs/ 目录里，文件名和用途对应，比如 model_names.txt、data_paths.txt。这样并行命令从一个文件读，和从另一个文件读，逻辑一目了然。命令行工具虽然追求极简，但真实项目里可维护性优先级更高。

7. 最后再分享一个输入源相关的实用小技巧

很多朋友在处理批量任务时，习惯把参数都放在一行里用逗号或其他符号分隔，然后期望 GNU Parallel 自己拆开。实际上更省事的是在生成输入源时就把它变成“一行一参数”的标准格式。你可以用 tr、awk、sed 轻松把列表转换成 parallel 喜欢的输入格式。这一步相当于在数据上游做了一次规范化，之后 GNU Parallel 的命令会变得非常简单，几乎不需要额外参数。

另一个建议是：从第4章开始，每次写完 parallel 命令，我强烈建议先用 --dry-run 验证再让任务真正跑起来。你可能觉得这增加了操作步骤，但在并行任务数量大的时候，这一步能帮你省下一整天的排查时间。我自己遇到的所有 parallel 事故里，有一大半是输入源格式问题，而这些全都能被 --dry-run 提前拦下来。

输入源是 GNU Parallel 的地基。把 stdin、-a、:::、--colsep、--xapply 这些概念彻底搞清楚，后面学替换字符串、任务控制、远程执行都会有顺水推舟的感觉。希望这份整理对你有用，也欢迎在实际使用中多试几种组合方式，跑通一两个真实任务后，你对输入源的理解会和看文档完全不一样。