运维脚本必须以 set -euo pipefail 开头确保安全，用 cd 锁定工作目录，getopts 严格解析参数并校验非空，关键命令后显式判断成败，临时文件用 mktemp 生成并 trap 清理，加锁需带超时和唯一标识。
脚本开头必须设置严格退出与环境隔离
不加 set -euo pipefail 的运维脚本，等于没设安全带。它强制：命令失败立即退出（-e）、未定义变量报错（-u）、管道中任一环节失败整体失败（pipefail）、禁止未声明选项（-o）。漏掉 -u 会导致 $var 写成 $VRA 却静默继续执行；漏掉 pipefail 会让 grep xxx log | head -1 在 grep 找不到时仍返回 head 的空结果，掩盖真实失败。
- 始终在脚本第一行后立即写：
set -euo pipefail - 用
set -x仅在调试时临时开启，生产环境禁用 - 用
cd "$(dirname "$0")"或cd "$(dirname "$(readlink -f "$0")")"锁定工作目录，避免相对路径失效
参数解析必须拒绝模糊输入
用 getopts 或 getopt 解析参数时，不处理未知选项、不校验必需参数、不区分短/长选项拼写，是多数脚本出问题的起点。比如 ./deploy.sh -e prod 中 -e 被误认为 --env，但实际脚本只认 -E，却因没设 : 在 getopts 中而静默忽略，最终走默认环境。
-
getopts模式下，选项字符串末尾加:（如":hE:p:"）才能捕获缺失参数值的错误 - 每个必需参数解析后立刻检查变量是否为空：
[ -z "$ENV" ] && { echo "Error: -E required"; exit 1; } - 避免直接用
$1、$2，它们不可读、难维护、无法支持长选项
命令执行必须显式判断成败与输出语义
运维脚本里最危险的写法是 systemctl restart nginx 后不检查状态，也不等服务真正就绪。重启成功 ≠ nginx 进程存活 ≠ 端口监听成功 ≠ 健康检查通过。更常见的是 curl -s http://localhost/health 返回 HTTP 200，但响应体是 {"status":"starting"} —— 这不是健康信号。
- 关键命令后必须跟
|| { echo "FAIL: systemctl restart nginx"; exit 1; }，不能依赖上层set -e（某些子 shell 或管道会绕过） - 服务类操作后加等待逻辑：
timeout 30s bash -c 'until ss -tln | grep ":80 "; do sleep 1; done' - 健康检查应解析响应内容：
curl -s http://localhost/health | grep -q '"status":"ok"'，而非只看 HTTP 状态码
日志与临时资源必须可控且可追溯
脚本运行中生成的临时文件、日志、锁文件，若不统一管理，轻则填满磁盘，重则引发并发冲突。常见陷阱包括：用 /tmp/deploy.lock 但不检测是否被其他实例占用；日志写入 /var/log/myapp.log 却没做轮转或权限检查；用 mktemp 但忘记清理。
- 所有临时文件路径用
mktemp -d或mktemp生成，退出前用trap 'rm -rf $TMPDIR' EXIT清理 - 日志统一写入
/var/log/$SCRIPT_NAME/$(date +%Y%m%d).log，并确保目录存在且属主正确：mkdir -p /var/log/mydeploy && chown root:adm /var/log/mydeploy - 加锁必须带超时和唯一标识：
if ! mkdir /var/run/mydeploy.lock 2>/dev/NULL; then echo "LOCKED"; exit 1; fi，比单纯 touch 文件可靠得多
健壮性不在功能多，而在每一步都预设“它可能出错”。尤其注意信号中断（SIGINT/SIGHUP）、磁盘满、权限突变、网络抖动这些非代码逻辑错误——它们不会让脚本语法报错，但会让线上服务停摆十分钟。