脚本中 $? 无法获取管道中上游命令的真实错误码，应使用 pipestatus 数组；子 shell 或命令替换会覆盖 $?，需内部保存；curl 需加 -f 参数才能使 http 错误返回非 0；systemctl is-active 应配合 –quiet 使用以准确判断服务状态。
脚本里 $? 拿不到真实错误码？
很多运维脚本用 if 判断命令成败，却在管道或子 shell 里丢了 $?——比如 cmd | grep xxx 后直接查 $?，拿到的其实是 grep 的退出码，不是 cmd 的。
真正想捕获上游命令的失败，得用 PIPESTATUS 数组：${PIPESTATUS[0]} 是第一个命令的返回码，${PIPESTATUS[1]} 是第二个……别依赖 $?。
- 管道中每个命令的退出码都独立存在，
$?只保留最后一个 -
set -o pipefail能让整个管道在任意命令失败时整体返回非 0，但不解决“想分别检查每个命令”的需求 - 如果用了
( cmd )或$(cmd)，$?就是子 shell 或命令替换的退出码，原命令的码已丢失——必须在子 shell 内部立刻保存，比如( cmd; echo $? > /tmp/ret )
判断 curl 失败该看返回码还是 curl -f？
curl 默认对 HTTP 错误状态（如 404、500）也返回 0，光靠 $? 判断会误认为成功。
加 -f（–fail）参数最省心：遇到 4xx/5xx 时强制返回非 0，和 shell 的 if 天然配合。但注意它不处理网络超时、DNS 失败等底层错误——那些本来就会让 curl 返回非 0。
- 不用
-f时，得手动解析响应头或 body，比如curl -s -o /dev/NULL -w '%{http_code}' ...，再判断数值 -
-f不影响重定向（3xx），它只针对客户端/服务端错误（4xx/5xx） - 如果脚本要区分“HTTP 404”和“连接被拒绝”，就得结合
-f和curl的具体错误输出，比如匹配Failed to connect或Could not resolve host
用 systemctl is-active 判断服务状态为什么总不准？
systemctl is-active service 返回的是服务当前“活跃状态”，不是“是否运行中”。比如服务崩溃后残留一个 inactive 状态，或被 stop 后还在 cleanup 阶段，都可能返回 failed 或 activating，但 $? 却是 0——因为它“执行成功了”，只是结果不是 active。
更靠谱的做法是组合判断：systemctl is-active --quiet service 把输出压掉，只靠退出码；或者用 systemctl show -p SubState --value service 拿更细粒度的状态。
-
--quiet是关键：它让命令只靠退出码表态，active或reloading返回 0，其余返回非 0 - 别用
systemctl status service | grep "active (running)"——输出格式不稳定，不同 systemd 版本可能换行或缩进 -
is-enabled和is-active完全不同：前者看开机是否启用，后者看当前是否跑着，别混用
写守护进程启动脚本时，怎么确认进程真起来了？
很多人用 service start 后立刻 ps aux | grep myapp，但进程可能还没完成初始化，或者刚 fork 就 exit，导致误判。
得等 + 验证：先用 systemctl start 或直接启动，再用 systemctl is-active --quiet 等状态就绪；如果没 systemd，就用循环检查端口或 pidfile，配合 timeout 防死等。
- 检查端口比
ps可靠：比如timeout 5 bash -c 'until nc -z localhost 8080; do sleep 0.5; done' - pidfile 必须由进程自己写，脚本不能代劳；且读取后要用
kill -0 $pid确认进程还活着 - 避免用
sleep 2这种固定等待——慢机器上不够，快机器上又浪费时间
异常返回码不是“有没有错”，而是“错在哪一层”：网络、权限、配置、进程生命周期……每层得用对应方式捕获，硬套 $? 会漏掉最多见的问题。