Bash中为何对$()赋值变量采用先定义后赋值写法？

这个写法其实是为了保留命令执行的退出状态码，避免被local命令本身的返回值覆盖——这是bash脚本里一个很容易踩的坑，我来给你拆解清楚：

核心原因：local会掩盖命令的错误状态 #

当你把local声明和命令赋值写在同一行时，整行命令的返回值是local命令的执行结果，而不是$(...)里外部命令的结果。local只要成功创建了变量就会返回0，哪怕后面的命令执行失败返回非0状态码，这个错误会被直接掩盖。

举个直观的例子：

# 错误示范：合并一行
local cur_ts=$(date +%s_invalid)  # date的参数错误，实际会返回1
echo $?  # 输出0，因为local执行成功，掩盖了date的错误

而拆分写法就能完美保留命令的真实状态：

# 正确写法：拆分两行
local cur_ts=
cur_ts=$(date +%s_invalid)
echo $?  # 输出1，正确反映了date命令的失败状态

这对于需要判断命令是否执行成功的场景至关重要——比如你想在date失败时抛出错误日志，拆分写法才能让你通过$?或者if判断来实现这个逻辑。

为什么直接赋值不需要拆分？ #

像local name=$1、local pair="$name => $value"这类场景，右边是参数展开或者字符串拼接，没有执行任何外部命令，不存在“命令执行失败”的情况，也就没有状态码需要保留。直接写一行既简洁又不会有问题，完全没必要多此一举拆分。

额外的小优势：兼容性 #

有些老版本的轻量shell（比如某些ash变种）对local var=$(command)的语法解析可能存在奇怪的兼容性问题，拆分写法能避开这类边缘情况，但这只是附加好处，核心原因还是状态码的保留。

内容的提问来源于stack exchange，提问作者Vadim Pushtaev