Bash 管道里的计数为什么带不出来：让循环在当前 shell 中读取输入
脚本把几行输出通过管道交给 while 循环，每读一行就增加计数；循环里面看起来正常，循环结束后却仍然打印零。在 Bash 的常见默认设置下，管道中的循环在子 shell 环境执行，修改的是那份环境中的变量，父 shell 的同名变量不会因此更新。
这与数据有没有读到是两件事，也与变量是否 export 不同。导出变量可以让子进程继承一个初始值，不能让子进程结束时把修改自动写回父进程。排查时先确认“这段赋值在哪个执行环境里发生”，比反复检查加法表达式更有效。
AI概念配图，非真实界面：以抽象物件说明本文主题，不代表运行结果。
用同一份输入对比两种连接方式
将下面代码保存为 demo.sh，用 bash --noprofile --norc +O lastpipe demo.sh 运行。命令只为这个演示进程明确关闭 lastpipe，不会修改系统或用户配置。这样管道样本的预期行为不依赖你当前终端是否曾开启相应选项，方便重复验证。
第一段把生产函数放在管道左侧，循环后的计数应为零。第二段把生产函数放入进程替换，让循环通过输入重定向读取它的输出，计数应为三。数据内容保持一致，因此差异来自执行位置，而不是筛选或逐行读取规则。
produce() {
printf '%s\n' alpha beta gamma
}
count=0
produce | while IFS= read -r line; do
count=$((count + 1))
done
[[ "$count" -eq 0 ]] || exit 1
printf 'pipeline=%s\n' "$count"
count=0
while IFS= read -r line; do
count=$((count + 1))
done < <(produce)
[[ "$count" -eq 3 ]] || exit 1
printf 'redirect=%s\n' "$count"
count=0
while IFS= read -r line; do
count=$((count + 1))
done < <(printf '')
[[ "$count" -eq 0 ]] || exit 1
printf 'empty=%s\n' "$count"保持循环的位置，重新连接输入
进程替换写成小于号后紧跟括号，它会为生产命令的输出提供可读取的入口；外面的输入重定向把这个入口交给循环。此时循环本身在当前 shell 运行，所以对 count 的赋值会保留下来。生产命令仍然在独立环境执行，不会因此共享所有变量。
第三段使用没有输出的数据源，验证空输入不会虚构一条记录。示例用 IFS= 与 read -r 保留每行内容的常见边界，但每行都由 printf 输出换行，因此这里只检验环境作用范围。如果输入可能没有末尾换行，还应为逐行读取规则单独补测试。
已有普通文件时，可以直接把文件重定向给循环，通常更清楚。需要收集数组或累计总数时，同样要让负责修改的循环位于后续使用这些变量的环境。相反，如果计算只在管道内部使用，完全可以把结果打印出来交给下一阶段处理。
把状态保留与失败检测分别处理
lastpipe 提供一个例外：启用它且作业控制未启用时，非后台管道的最后一段可以在当前 shell 中运行。不能因此假定所有 Bash 会话都如此，更不能把这种行为直接推广到所有 shell。可复用脚本应明确运行环境，避免依赖交互终端的偶然配置。
进程替换解决了循环变量保留的问题，却没有自动把生产者的退出状态纳入循环结果。生产者先输出两行再失败时，循环仍可能顺利读完这两行。若数据完整性很重要，需要另外检查生产者是否成功，再决定能否使用累计结果。
一种适合批处理的设计是先把生产结果写到受控临时文件，确认生产命令成功后再读取文件。另一种是明确管理后台进程并等待其结果。选择哪一种取决于数据体积和时延要求，不能把“最后打印三”当作整条任务链已经成功的证据。
验收时同时保留正常输入、空输入和生产失败三类用例，并分别检查数据条数、累计值与退出状态。把这些维度拆开，才能看清究竟是循环没有运行、变量留在了子环境，还是上游只生成了部分数据，后续修复也会更直接。
