$?保存上一条命令的退出状态，0表示成功，非0（1–255）表示失败；其值仅保留一次，后续命令会立即覆盖，故需立即使用或存入变量，且优先用if或&&/||直接判断而非手动检查。
用 $? 拿上一条命令的退出状态码
执行完任意命令后，Bash 会把它的退出状态（exit status）存进特殊变量 $?。它是个整数，0 表示成功，非 0（通常是 1–255）表示失败。这个值只保留「上一条」命令的结果，下一条命令一执行，$? 就被覆盖了。
常见错误是隔了一行再读 $?，比如：
ls /nonexistent echo "status: $?"
看着没问题，但如果中间插入了其他命令（哪怕是 echo、printf），$? 就变成那个命令的返回值了。实操建议：
- 在目标命令后**立刻**使用
$?，不要穿插任何其他命令 - 需要多次判断或后续复用时，**马上存进普通变量**：
ret=$? - 别用
echo $?; echo $?; echo $?;测试——第二、三次输出的是前一次echo自己的返回值（通常是 0）
用 if 直接判断命令成败，比查 $? 更安全
if 语句底层就是靠命令的退出状态工作，不需要手动读 $?。它更简洁、不易出错，也符合 Bash 的惯用写法。
例如检测文件是否存在并可读：
if [[ -r "/etc/passwd" ]]; then echo "OK" else echo "Failed with status $?" fi
注意：这里的 $? 是 [[ -r ... ]] 的结果，但你根本不用关心具体数值——if 已经替你做了判断。实操建议：
- 只要逻辑是「成功做什么 / 失败做什么」，优先用
if command; then ... else ... fi - 避免写成
command; if [ $? -eq 0 ]; then ...——多一次变量读取，且容易漏掉$?覆盖风险 -
||和&&也是基于退出状态的快捷写法：rm file || echo "delete failed"
管道命令的退出状态要小心：$? 只反映最后一条，要用 $PIPESTATUS
执行 cmd1 | cmd2 | cmd3 后，$? 只保存 cmd3 的退出码。如果想检查管道中某一步是否失败（比如 grep 找不到内容导致 cmd2 返回 1），$? 就不够用了。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
$PIPESTATUS 是一个数组，按顺序存着每条命令的退出状态。比如：
ls /nope | grep txt 2>/dev/null
echo "${PIPESTATUS[@]}" # 输出类似：2 1这里 ls 失败返回 2，grep 因输入为空而返回 1。实操建议：
- 需要诊断管道各环节时，第一时间想到
$PIPESTATUS，不是$? - 用
${PIPESTATUS[0]}拿第一个命令的状态，${PIPESTATUS[1]}拿第二个……索引从 0 开始 -
$PIPESTATUS在每次命令执行后刷新，但**只对管道有效**；普通命令后它和$?无关
函数和子 shell 中的退出状态继承与截断
函数内部的 return 值、子 shell（(...)）里命令的 exit 码，都会成为外层调用的退出状态。但要注意作用域和覆盖时机。
例如：
myfunc() { ls /nope; return 42; }
myfunc
echo $? # 输出 42，不是 ls 的 2这里 return 42 覆盖了 ls 的状态。实操建议：
- 函数末尾没写
return，默认返回最后一条命令的$? - 子 shell 中用
exit N，外层能拿到这个N；但子 shell 里不写exit，就拿不到内部命令的状态（除非显式exit $?） - 别依赖嵌套层级太深的
$?链——先存变量，再传参或return，逻辑更可控
真正容易被忽略的点是：状态码不是“错误信息”，它不告诉你为什么失败，只告诉你“是否失败”。调试时得结合命令本身的输出（stderr）、文档说明（哪些非零码对应什么含义），以及像 $PIPESTATUS 这种细分机制——否则光看 $? 等于只看了半张诊断单。
