为什么开发者都该学一点 Shell 脚本
每天打开电脑，总有一堆机械又不得不做的活：备份某个目录、拉取代码、重启服务、批量改文件名、把日志里报错的那几行捞出来……如果每次都靠手敲命令或点鼠标，不仅慢，还容易漏。Shell 脚本自动化就是把这一系列重复劳动“打包”成一个命令，敲一下就全自动跑完。它不需要你成为运维专家，只要你会几条基础 Linux 命令，就能用 Shell 脚本把效率翻倍。这篇文章是我从纯手工到“能脚本就脚本”的过程中，沉淀下来的入门与避坑心得。
先想清楚：什么值得写成脚本
不是所有事都该脚本化。判断标准很简单：一件事你一周要做超过两次、步骤固定、且每次操作几乎一样，那它就值得写成脚本。比如“压缩昨天的日志并上传到备份盘”“每周一清理临时文件”“部署前先跑测试再打包”。反之，那种一次性的、步骤还在变的探索性操作，先用手敲理顺流程，等模式稳定了再固化成脚本，反而更省心。我吃过急着脚本化的亏：流程没定型就写，结果脚本改了七八版，比手动还累。
从第一行走起：shebang 与参数
一个最基础的脚本长这样：第一行 #!/bin/bash 告诉系统用哪个解释器；后面就是把你平时敲的命令按顺序排好。让脚本真正好用的是参数：$1、$2 代表调用时传进来的第一个、第二个参数，用 $@ 可以遍历所有参数。比如写个 backup.sh，调用时传 ./backup.sh /home/me 就能备份指定目录，比写死路径灵活太多。记得给脚本加执行权限 chmod +x backup.sh，否则敲 ./backup.sh 会提示权限不足。
让脚本“会说话”：日志与退出码
写好脚本后，最怕它静悄悄地失败。养成两个习惯：一是用 echo 在关键步骤打印进度，必要时把输出重定向到日志文件；二是用 exit 0 表示成功、exit 1 表示失败，这样脚本就能被其他脚本或 cron 判断成败。配合 set -e（遇到错误立即退出）能避免“前半段挂了后半段还在乱跑”的连环翻车。
定时跑：把脚本交给 cron
脚本写好了，还得有人按时按点执行。crontab -e 就是干这个的：一行表达式定义“几分几时哪天跑”，比如 0 2 * * * /home/me/backup.sh 就是每天凌晨两点自动备份。对经常 SSH 到远程服务器干活的人，我强烈建议先看看 tmux 终端复用器上手指南：SSH 断了工作也不丢，远程开发效率翻倍，把长任务丢进 tmux 会话，断线也不怕；再把定时任务交给 cron，二者配合，远程工作流才算真正稳。
和版本控制交朋友
脚本也是代码，理应进版本库。把 ~/scripts 目录用 Git 管起来，每次改动都提交，既能回滚又能多机同步。关于怎么写好提交信息、怎么修改历史提交，Git 提交信息管理：如何写好 commit message 与修改历史提交 这篇讲得很实用，照着做你的脚本仓库会清爽很多。我自己的习惯是：每个脚本一个文件、名字见名知意、README 里写清用途和参数，半年后回看也不懵。
别重复造轮子：复用站内的小技巧
脚本里经常要处理网页、接口或站点内容。如果你也折腾 WordPress，WordPress 开发小技巧：从图片链接反查附件 ID 与几个实用钩子 里那段“从链接反查资源”的思路，完全可以改成脚本里的自动提取逻辑，把手动查数据库变成一行命令。技术活儿的本质就是不断把零散知识串成工具链，今天攒一个脚本，明天接一个钩子，久而久之你的效率就甩开纯手工党一大截。
回到开头：Shell 脚本自动化的门槛比想象中低得多。今晚就挑一件你本周重复做过的琐事，把它写成第一个脚本吧——当看到回车后任务自己跑完的那一刻，你会理解为什么老鸟都说“能脚本就别手动”。
暂无评论内容