开发者的一键脚本：把重复操作收进一个入口
LavenderInk
7 分钟阅读
每天开工要依次切目录、拉代码、装依赖、起服务、开日志；部署前要打包、跑测试、推镜像、重启。这些步骤每次都一样，却每次都手动敲一遍，出错的概率随步骤数线性增长。一键脚本的价值不是"炫技"，是把一串固定操作收成一个可重复、可追溯、不会漏步的入口。
什么值得收进脚本
判断标准只有一条：过去一周你手动重复过三次以上的复合操作。单次命令（比如 git pull）不值得包；但"进项目目录→更新→装依赖→启动"这种多步序列值得。临时一次性任务别脚本化，写完即弃反而更省心。经验上，值得脚本化的操作通常带三个特征：步骤多、有固定顺序、漏一步就会出问题。
一个最小可维护的结构
别把所有逻辑糊进一个长文件。按"子命令"组织，让一个脚本承担一类相关操作：
#!/usr/bin/env bash
set -euo pipefail
cmd_build() {
echo "构建中..."
npm run build
}
cmd_dev() {
git pull
npm install
npm run dev
}
case "${1:-}" in
build) cmd_build ;;
dev) cmd_dev ;;
*) echo "用法: $0 {build|dev}" >&2; exit 1 ;;
esac
set -euo pipefail 是三条安全线：-e 任一步失败立即停；-u 用了未定义变量直接报错；-o pipefail 让管道里任一段失败都算失败。没有它们，前面命令静默失败、后面接着跑，是最难查的一类 bug。
让脚本跨环境可用
硬编码绝对路径是脚本最常见的早衰原因。用相对路径或环境变量表达位置：
PROJECT_DIR="${PROJECT_DIR:-$HOME/projects/app}"
cd "$PROJECT_DIR"
"$HOME/projects/app" 这类变量引用一定加双引号，否则路径里含空格会断成多段。需要跨平台时，判断系统再选命令：
if [[ "$OSTYPE" == "linux-gnu"* ]]; then
open_cmd="xdg-open"
elif [[ "$OSTYPE" == "darwin"* ]]; then
open_cmd="open"
fi
参数与配置分层
脚本跑久了会冒出"这次想跳过装依赖""那次要指定环境"的需求。把这类变化点做成参数或环境变量，而不是再复制一份脚本：
SKIP_INSTALL="${SKIP_INSTALL:-0}"
[[ "$SKIP_INSTALL" == "1" ]] || npm install
频繁变化的配置（如目标主机、版本号）放 .env 或同目录配置文件，脚本读取，避免改脚本本体。记住脚本本体应该进版本库，含敏感值的配置文件进 .gitignore。
把多个脚本的职责拆开
当一个入口要做的事变多，别把所有逻辑堆进一个文件直到它上千行。按职责拆成被调用的小函数或独立脚本，主脚本只负责"编排顺序"：先调 A，成功再调 B。这样每个子脚本能单独测试，主脚本读起来也像一份步骤清单。经验上，单文件超过两屏就开始难维护，这时该拆了。拆出来的公共函数可以放进一个 lib.sh，各脚本 source 它复用，避免同样的错误处理代码复制五份、改一处漏四处。
调试与dry-run
脚本出问题，先别盲改。在关键分支前加 set -x 让每一步执行的命令都打印出来，看清实际跑的是哪条、变量替换成了什么。对破坏性强（删文件、推远程）的步骤，做一个 DRY_RUN 开关：开了只打印将要执行的命令、不真跑，确认无误再关掉执行。
run() {
if [[ "${DRY_RUN:-0}" == "1" ]]; then
echo "[dry] $*"
else
eval "$@"
fi
}
run "rm -rf $BUILD_DIR"
这种"先看后做"的护栏，在脚本第一次上岗、你还不完全信任它时尤其重要。等它在几十次运行里都表现稳定，再考虑去掉 dry-run 提示。
日志与可观测
一键脚本跑挂时，最怕"卡在哪一步"说不清。两个习惯能救命：每步开头 echo 当前在做什么；把整段输出重定向到日志文件便于回看：
log() { echo "[$(date +%H:%M:%S)] $*"; }
log "开始部署"
复杂任务可用 tee 同时打到屏幕和文件：do_task 2>&1 | tee deploy.log。CI 里跑脚本时，非零退出码会自动标记失败，所以前面的 set -e 在这时格外关键。
几个踩坑点
权限忘了加：chmod +x script.sh 才能 ./script.sh，否则只能 bash script.sh。Shebang 写错：macOS 上 /bin/sh 可能是旧版，用到 bash 专属语法就写 #!/usr/bin/env bash。脚本里混用相对路径：脚本从哪个目录被调用，相对路径就基于哪，依赖当前工作目录的脚本换个位置调用就找不到文件，关键路径用绝对路径或 cd 到确定目录再操作。Windows 换行符：\r\n 会让 shebang 变成 #!/bin/bash\r 而报"bad interpreter"，跨平台共享脚本时注意用 LF。
何时收手
脚本不该长成第二个系统。当你的脚本开始需要子命令帮助文档、配置校验、错误处理分支比主逻辑还多，就该考虑换成专业的任务运行器或 Makefile，甚至拆分进项目本身的工具目录。一键脚本的甜区是"十步以内、一个月改不了几次"的重复操作；超出这个尺度，维护脚本本身就成了新的重复劳动。
还有一个心智上的收益：把流程写进脚本，等于把"怎么做"从脑子里搬到文件里，新人接手时读脚本比听口述可靠，交接成本明显下降。这比省下的那点敲命令时间更值钱。
浏览 0
点赞 0
评论 0