mkfifo基于内核阻塞语义实现硬限流，要求读写端同时打开才能通信，天然防死锁、不惧崩溃；而xargs -P和&+wait缺乏并发控制与异常恢复能力。
为什么用 mkfifo 而不是 xargs -P 或 & + wait
因为 xargs -P 在任务中途崩溃、超时或被信号中断时，会卡住未完成的子进程，且无法回收已占用的并发槽位；& + wait 更是完全不控并发，全靠人工数 wait 数量，一错就满屏进程。而 mkfifo 基于内核级阻塞语义：只有读写两端同时存在，数据才能流通——这个“必须配对”的特性天然构成硬限流，不依赖轮询、不惧崩溃、无竞态。
exec 绑定文件描述符时为什么用 或 <code>>
单向打开（如 exec 3）会导致后续无法写回令牌；只写（<code>exec 3> fifo）则第一次 read -u3 就失败——FIFO 要求至少一个读端和一个写端同时打开才可通行。用 是以读写模式打开，让同一个 fd 既能 read 消耗令牌，也能 echo >&3 归还令牌。这是整个机制能闭环的关键一步。
初始化令牌时 echo 写入顺序和 read -u 阻塞行为的关系
初始化阶段往 FIFO 写 N 个换行符，本质是预置 N 个“可用槽位”。但注意：echo 必须在 exec 绑定之后、任务循环之前执行，否则可能因读端未就绪导致写操作阻塞；而每个任务里的 read -u3 会严格阻塞，直到 FIFO 中有数据可读——也就是前一个任务释放了令牌（echo >&3），才会继续向下执行。这种“取-用-还”链条不可跳过，漏掉任意一环都会死锁。
- 常见错误：在
for循环里直接read -u3后没写echo >&3，任务退出后令牌永久丢失 - 更隐蔽的坑：任务里用了
set -e或exec替换 shell（如exec python script.py），会导致echo >&3根本不执行——必须用trap 'echo >&3' EXIT保底 - 路径安全：FIFO 文件名建议带
$$（如/tmp/fifo.$$），避免多实例冲突；创建后立即rm -f，靠 fd 持有句柄，防止残留文件污染
并发数设太高或太低的实际影响
设太高（比如 200）会让管理机 CPU 和内存瞬间吃紧，尤其当任务本身是 ssh/scp 这类开销大的操作时，连接数打满反而拖慢整体；设太低（比如 1）虽安全，但无法压满专线或磁盘 I/O。真实场景中，应结合任务类型调优：ping 类轻量任务可设 50+，scp 类重 IO 任务建议 3–8，ssh + tar 类建议 ≤5。没有通用最优值，只有当前环境下的合理值。
真正容易被忽略的是：FIFO 的阻塞是“打开即阻塞”，不是“读时才阻塞”。一旦某个任务在 read -u3 卡住，它就占着 fd 不放，后续所有同 fd 的读操作都排队等它——所以 trap 的注册位置、echo 的执行时机、以及是否允许任务自身提前退出，这三个点任何一个出问题，整个并发池就停摆。
