自动化脚本的工程习惯：从"能跑"到"敢反复跑"
一个脚本第一次跑通，往往是最容易的阶段。难的是三个月后另一个人接手时敢改，半年后半夜自动触发失败时能定位，以及同一条脚本在生产环境重复执行第二遍时不会把状态搅乱。自动化脚本和一次性命令的根本区别就在这里：它的价值不在于"省了一次手工操作"，而在于成为可重复依赖的系统组件。一旦被定时任务、CI/CD 流水线或运维流程调用，脚本就不再是个人终端里的草稿，而是需要按工程标准来对待的代码。
先让失败是确定的
脚本最危险的状态不是报错退出，而是出错了却假装没事。默认情况下，Bash 在管道中某条命令失败时会继续往下执行，未定义变量会被静默展开为空字符串，这些行为在交互式 shell 里或许可以接受，在无人值守的自动化中却是事故的温床。
set -Eeuo pipefail 是让失败变得确定的最直接手段：-e 让任意非零退出码终止脚本，-u 捕获未定义变量，-o pipefail 让管道中任何一环的失败都能传导到整体退出码，-E 则让 ERR trap 在函数和子 shell 中同样生效。需要警惕的是，-e 并非万能，它在条件判断、&&/|| 列表以及某些命令替换场景中有已知的例外。因此不能只依赖 set -e 就认为错误处理已经完备，关键写操作仍然需要显式的错误检查和清晰的退出码。|| true 不是不能用，但每一次使用都应该是一次有意的"忽略"，而不是图省事的消音；否则 -e 提供的保护就被悄悄掏空了。
配套的做法是 trap：在 ERR 上挂一个处理函数，记录失败的命令、行号和退出码；在 EXIT 上清理临时文件或锁。一个没有 trap 的脚本，失败时留下的临时目录和半完成状态，往往比失败本身更难收拾。
幂等不是可选项
自动化脚本被重试是常态，不是例外。网络抖动、超时、调度器重试、人为补跑，都会让同一条脚本在相同或近似相同的初始状态下再次执行。如果脚本的设计假设是"只跑一次"，那么第二次执行要么报错，要么产生重复副作用------而两者都是故障。
幂等的核心是"检查后配置"而不是"总是执行"。创建用户之前先确认用户是否存在；写配置文件之前先判断内容是否已经匹配目标状态；申请资源时使用唯一的幂等键，让重复提交返回同一结果而不是创建第二份。一个典型的反面模式是"先检查存在性，再创建"：在检查与创建之间如果被中断，下一次执行会看到一个半存在的状态，而脚本的逻辑完全无法处理它。更好的做法是把创建操作本身设计成幂等的------mkdir -p 之所以经典，就是因为它把"不存在则创建"和"已存在则跳过"合并成了一个原子语义。
幂等性还有一个常被忽略的维度：脚本执行失败后的残留状态。一条删了一半文件的清理脚本、一个装了一半的依赖安装流程，在下一次执行时面对的是上一次留下的中间态。脚本需要能够识别并处理自己的残留，或者把操作设计成可以在任意步骤安全重入。做不到这一点的脚本，本质上只有"第一次执行"是可信的。
日志是给未来的自己留的现场
交互式执行时，人可以盯着屏幕判断卡在哪一步。自动化脚本没有这个条件。日志是唯一的现场记录，它的质量直接决定了故障排查是五分钟还是五小时。
好的日志至少做到三件事：带时间戳和脚本名，让多条日志混在一起时还能归因；记录关键操作的前后状态，尤其是写操作修改了什么、从什么改成了什么；把错误输出和正常输出分开，不要把 stderr 一股脑重定向到 /dev/null。结构化并不一定意味着 JSON，但对于需要被日志系统采集的脚本，输出可解析的格式（时间、级别、消息、上下文）会让后续的聚合和告警省很多事。
一个容易踩的坑是"日志太多"和"日志太少"之间的失衡。每行命令都打一条日志，真正出错时关键信息会被淹没；只在开头和结尾打日志，失败时又不知道断在哪一步。比较务实的做法是：入口和出口各一条，每个有副作用的操作前后各一条，错误路径无条件记录。调试级别的细节可以通过环境变量控制，但错误和关键状态变更不应该依赖调试开关才出现。
配置和凭据不应该是脚本的一部分
把环境相关的值写死在脚本里，是自动化代码腐化最快的路径之一。开发、测试、生产环境的路径、地址、超时参数各不相同，硬编码意味着同一份逻辑要维护多个副本，或者每次部署前手动改一遍------而手动改的那一遍，就是事故的高发窗口。
配置外置化是基本要求，但仅仅把变量挪到文件里还不够。参数需要校验：必填项缺失时在脚本开始时明确报错，而不是在执行到一半时才因为空值产生难以理解的副作用。布尔开关和路径参数要有合理的默认值，但默认值本身应该显式写在用法说明里，而不是靠读代码去猜。
凭据的处理需要更严格的纪律。硬编码的密码、token 和密钥一旦进入版本库，即使后来删除，历史记录里仍然可追溯。正确的位置是环境变量、操作系统的密钥链或专门的 secret 管理服务。同时，脚本申请权限时应当遵循最小权限原则：只需要读某个目录，就不要授予整个文件系统的读权限；只需要调用某个 API 的特定 scopes，就不要申请全量授权。脚本的权限范围，就是它出错时可能造成的最大破坏范围。
版本控制、审查和"能停下来"的能力
脚本放在个人 home 目录里，和放在版本库里并经过审查，是两种完全不同的工程状态。版本控制解决的远不止"找回旧版本"：它让每一次变更都有记录，让审查者可以在合并前看到"这条 sed 命令会作用在哪些文件上"，让回滚成为一个可执行的动作而不是凭记忆重写。脚本应该和应用代码放在同一个仓库或同一套治理流程下，而不是游离在代码审查之外。
与版本控制配套的是 dry-run 能力和可回滚设计。对删除、覆盖、批量修改、权限变更这类不可逆操作，脚本应当支持"先展示、后执行"：dry-run 模式输出将要修改的对象清单和变更前后的值，确认后再真正施加变更。这并不是要求每一条脚本都做成完整的 plan/apply 系统，但至少对于影响面超过单个文件或单个资源的操作，缺少预览能力就意味着操作者只能靠信任来按下回车。回滚同样需要在设计阶段考虑：写操作之前是否留下了可恢复的备份，失败时是否能够停在一致的状态，而不是在"改了一半"的地方留下一个既不是旧状态也不是新状态的残局。
最后，用检查清单代替直觉
脚本的常见缺陷有很强的模式性：未引用的变量、忘记处理的退出码、rm -rf 前面没有保护、硬编码的路径、只在某个 shell 版本上能跑的语法。ShellCheck 这类静态检查工具能在几秒内捕获其中很大一部分，把它接入 CI 或 pre-commit 的成本极低，收益却远高于事后排查。对于逻辑较复杂的脚本，bats 之类的测试框架可以用很小的用例覆盖参数解析、幂等分支和错误路径，避免每次修改都靠手工重跑全部场景来确认没有回归。
自动化脚本的最佳实践，归根结底不是一套需要背诵的规则，而是一种判断标准：这条脚本在别人手里、在半年后的生产环境里、在第二次执行时，是否仍然可读、可改、可停。满足这三点，它才真正配得上"自动化"这个词，而不是把手工操作的风险换了一种形式藏进代码里。