Bash local 命令替换：子命令返回失败，为什么紧接着的状态却是零
函数里用一行代码声明局部变量并收集命令输出，随后检查问号参数，发现生成命令明明失败，状态却是零。原因是这一行实际执行了 local 内建命令：声明成功可以盖住命令替换里那次失败，变量有内容也不代表生成过程完整。
先分清这一行执行的是谁
local value=$(produce) 包含一个命令名 local，输出展开后交给它处理；如果合法局部变量顺利创建，看到的就是声明命令的状态。拆成 local value 和 value=$(produce) 后，后一行没有普通命令名，其状态才采用本次命令替换的状态。
下面的 produce 故意先输出 partial，再返回二十三。这样可以排除“有文字就是成功”的错误判断。第一个函数展示合写后的状态，第二个函数把赋值直接放进 if，并在 else 第一时间保存状态，随后交回调用者。
保存为 demo.sh，用 bash demo.sh 执行。脚本只用 Bash 内建功能，不下载文件，不调用服务。这里不依赖自动退出选项，而是显式断言预期状态，让两个分支都能被完整观察。
配图为 AI 生成的概念插图，用抽象物件说明本文关系，并非真实软件截图或运行输出。
set -u
produce() {
printf 'partial'
return 23
}
combined() {
local value=$(produce)
local rc=$?
printf 'combined: status=%s value=%s\n' "$rc" "$value"
[[ $rc -eq 0 && $value == partial ]] || return 1
}
separated() {
local value rc
if value=$(produce); then
printf 'unexpected success\n' >&2
return 99
else
rc=$?
printf 'separated: status=%s value=%s\n' "$rc" "$value"
[[ $rc -eq 23 && $value == partial ]] || return 98
return "$rc"
fi
}
combined || exit 1
if separated; then
exit 2
else
received=$?
fi
[[ $received -eq 23 ]] || exit 3
printf 'caller received: %s\n' "$received"输出和退出状态必须成对使用
第一行打印 status=0 value=partial，第二行打印 status=23 value=partial，最后调用者收到二十三。两次生成过程完全相同，都是先给出部分文字再失败；改变的只是外层收集输出的写法。合写造成的成功状态不能证明生成结果可用。
拆开之后，失败的赋值仍可能把部分输出存进变量，所以错误分支应决定丢弃、留作诊断还是允许继续。不要只修复退出码，又把同一份 partial 当成完整配置继续处理。若结果会用于路径、选项或文件内容，消费它之前必须经过成功分支。
保存问号参数应紧接目标命令。示例进入 else 后先执行 rc=$?，然后才打印日志；若先输出一条提示，问号参数就可能只代表打印是否成功。最后使用保存好的状态返回，既保留原因，也避免后续断言或格式化覆盖它。
声明没有错，责任需要拆清楚
local rc=$? 在这里可以保存已经存在的状态，因为右侧只是展开数值，没有再运行一个可能失败的生产命令。真正危险的组合，是需要检查的新命令被藏进声明参数里。代码审查时应看有没有命令替换，而不是机械禁止所有带初始值的局部声明。
也不要为了简写改成 if ! value=$(produce)，然后在分支里期待问号参数仍为原始失败码；逻辑取反本身会改变条件的状态。普通 if 与 else 已能把成功和失败分开，更适合同时保留具体错误数字。
一个赋值里若塞入多个命令替换，最终状态也不足以代表每一步都成功。对下载、解压、解析这样的连续流程，按步骤收集和检查结果更易复核。函数输出负责传递数据，返回状态负责传递完成情况，调用方应明确处理两者。
验收保留三个版本的生产者：无输出成功、有输出成功、有部分输出失败。这样可以确认空结果是合法数据还是失败迹象，也能发现错误日志是否意外混入结果。本文的二十三只是教学选择的状态，实际脚本应沿用所调用程序的错误约定。
资料核对日期：2026年10月2日（北京时间）。最终展示代码在 GNU Bash 5.2.37 中独立运行并通过全部断言。
