先聊个真实的场景。你辛辛苦苦写了一个脚本本地跑得欢天喜地结果哪天文件数量过了万、某个日志名字里带空格、一条 grep 恰好匹配不到内容导致脚本中断、服务器重启后 crontab 里的任务静默失败——到那时候你就会明白高级 Shell 脚本和入门 Shell 脚本之间差的那一大截根本不在背了多少条命令而在整套工程化思维。我这些年写过的高级 Shell 脚本附带示例代码不算少从日志归档、批量重命名、参数解析模板到监控告警脚本都有实战沉淀。这篇文章我会按自己的真实使用习惯来写先把“高级”这两个字拆清楚再逐个讲参数扩展、数组、函数、trap 这些核心技巧接着给出三个你可以直接保存成.sh文件就开工的完整示例最后整理一份常见问题速查和免费脚本的落地改造建议。不论你是刚学完 Shell 语法准备写生产级脚本的新手还是写了好几年脚本但总觉得自己代码像“一次性工具”的运维同学这篇都值得你花十分钟读完。1. 高级Shell脚本“高级”在哪里重新理解脚本的定位1.1 入门脚本与工程级脚本的差距很多人写 Shell 脚本水平停留在“能用”阶段。比如想统计日志里 ERROR 出现的次数一个新手十有八九会这么写#!/bin/bash grep ERROR /var/log/app/app.log | wc -l这条命令确实能跑但稍微追问几句就露馅了日志文件不存在怎么办当天确实没有 ERROR和“日志文件根本没生成”这两种情况脚本能区分吗grep 没有匹配内容时返回非 0 退出码管道后面的 wc -l 反而正常执行最终结果都是打印一个数字到底是 0 个错误还是脚本本身已经出错了你完全无感。工程级脚本要考虑的问题完全是另一个维度路径不存在要显式报错并退出参数缺失要给默认值或帮助信息命令失败要决定是“立即中断”还是“捕获后继续”临时文件在脚本被杀掉时能不能被自动清理crontab 里 PATH 和交互终端不一致脚本会不会在半夜里静默失败。这些听起来不复杂但几乎每条都对应一个真实的事故现场。我见过不少运维同学的脚本线上出了问题后排查半小时最后发现是变量名拼错了——shell 默认把未定义变量当成空字符串处理不报错、不停顿一路安静地跑完结果就是“脚本成功执行了但什么都没做”。1.2 高级脚本要解决的四类实际问题关注点入门习惯工程级做法出错处理让脚本继续跑完出错即停或明确分支出处理输入校验直接使用$1校验默认值、格式、路径是否存在可读性全部堆在主流程里函数拆分、模块化、加注释环境适配只保证本机能跑尽量兼容 POSIX 或声明依赖、使用绝对路径说白了高级 Shell 脚本不是在语法上炫技而是对“可预期的失败”有预判和响应。你写的不是一条命令而是一个小型程序要有输入、处理、输出、异常分支和退出策略。带着这个认知去学下面的技巧方向就对了。2. 实战派必学的核心技巧参数扩展、数组与函数设计2.1 参数扩展写脚本最少要掌握的八种变形Shell 脚本里大量工作其实是字符串和路径处理。很多同学一上来就调sed、awk、cut每条命令都要起一个外部进程在循环里反复调用性能差不说代码也支离破碎。其实 Bash 自带的参数扩展就能搞定绝大多数场景而且快得离谱。我按使用频率给你列八个直接用例子说话config_dir${CONFIG_DIR:-/etc/myapp} # 变量为空时使用默认值 : ${REQUIRED_PARAM:?缺少必填参数} # 变量为空时报错退出 echo ${#filename} # 获取字符串长度 filenameproject-backup-2024-01-15.tar.gz echo ${filename##*.} # 输出 gz双井号掐掉最长前缀 echo ${filename%.tar.gz} # 输出 project-backup-2024-01-15去掉尾部 echo ${filename//-/_} # 全局替换把 - 换成 _这几个符号很容易记混分享一个我自己的记忆方法#在键盘上靠近数字左侧天然和“开头”绑定用来删除前缀%靠近数字右侧和“结尾”绑定用来删除后缀。单个#或%是最短匹配双写##和%%就是贪婪的最长匹配。实际场景里参数扩展最常见的用途是解析路径和文件名。比如你从下载目录拿到一个 URL想提取文件名直接用${url##*/}就行根本不用起一个basename进程想把data.txt改成data_20240115.txt${file%.txt}先把后缀去掉再拼上日期干净利落。另一种高频用法是给脚本参数做防护。${1:-default}让你在用户没传参时不至于拿到空值${VAR:?错误信息}能在变量缺失时直接把错误打出来并退出这比你自己写if [ -z $VAR ]要省三行代码。2.2 数组与关联数组告别零散变量初学 Shell 时很多人喜欢用普通变量拼接一组数据filesa.log b.log c.log然后靠 for 循环分词去遍历。这在文件没有空格时勉强能跑但只要文件名里带一个空格整个循环就崩了。数组才是正解files(/var/log/app/*.log) # 直接把匹配结果放进数组 for f in ${files[]}; do echo $f done注意${files[]}这个写法引号绝对不能省。一旦去掉引号数组里的元素会被再次按空格切分你的脚本立刻回到“处理不了带空格文件”的阶段。这一点在第五章我会再展开说。如果说普通数组解决的是“列表”问题关联数组解决的就是“映射”问题。处理复杂脚本时我特别喜欢用关联数组把配置集中管理declare -A service_ports service_ports[nginx]80 service_ports[mysql]3306 service_ports[redis]6379 for srv in ${!service_ports[]}; do echo $srv - ${service_ports[$srv]} done${!service_ports[]}里的感叹号表示取所有键这是个很容易忽略的细节。关联数组的价值在于当你有几十个服务要批量操作时不用写几十个 if-else一个循环全搞定。我在多机部署脚本里就经常用关联数组存“服务名-端口-目录”这种三元组。2.3 函数设计返回值、局部变量与模块化Shell 函数和编程语言里的函数不太一样它本质上就是一段命令的复用。但既然叫函数就该有函数的样子。最核心的两个原则变量一定要local返回值一定要显式。check_dir() { local dir$1 if [[ ! -d $dir ]]; then log error 目录不存在: $dir return 1 fi return 0 } if check_dir $BACKUP_DIR; then echo 目录正常 fi不加local的话函数里的dir会变成全局变量脚本一大到处都在悄悄改同一个变量排查起来想死。返回值这块记住一个约定0 表示成功非 0 表示失败调用方用if 函数名; then就能判断。函数用多了自然会走到模块化那一步。我习惯把log、check_param、send_alert这类通用能力抽到一个common.sh里每个业务脚本头部source ./common.sh就直接用。这样十几个脚本共用一个日志函数想改日志格式只动一个文件比在每个脚本里复制粘贴一百遍强太多。3. 让脚本从“能跑”到“能扛”工程化四件套3.1 set -euo pipefail 组合功能拆解我写高级 Shell 脚本有个习惯shebang 下面固定三行任何脚本都先写上#!/usr/bin/env bash set -euo pipefail这一行组合拳分别干了三件事。set -e脚本里任何一条命令返回非 0 退出码时立即终止整个脚本。这能避免“第一个命令失败了后面还在傻乎乎地往下跑”的连锁事故。但它有个经典的坑如果你确实预期某条命令会失败比如 grep 可能匹配不到直接写在裸命令位置就会被set -e秒杀。解决办法是把它放进if条件里或者显式补|| true。set -u使用未定义的变量直接报错。这是抓拼写错误的神器。之前说的“变量名写错但脚本安静跑完”的惨案靠它就能避免——变量没定义脚本当场退出错误信息里直接指出哪一行哪个变量有问题。set -o pipefail管道中任何一条命令失败整个管道的返回值就是非 0。比如cmd1 | head这种写法如果cmd1中途崩了但 head 正常结束默认情况下管道返回 0错误就被吞掉了。加上 pipefail 后这类隐蔽失败立刻暴露。我见过有人担心这三件套太激进会把正常的业务脚本卡死。实际用下来代价远远小于收益。真遇到“预期会失败”的场景就用if或|| true去显式兜底这本来就是逼你写清楚逻辑。3.2 日志函数与调试技巧脚本没有日志等于飞机没有黑匣子。日志函数是所有脚本我都先写的基础设施log() { local level$1 shift printf [%s] [%s] %s\n $(date %Y-%m-%d %H:%M:%S) $level $* }使用的时候log info 开始备份、log error 磁盘空间不足输出带时间戳一看就知道脚本跑到哪一步挂了。如果脚本要进 crontab记得把日志重定向到文件30 2 * * * /bin/bash /opt/scripts/backup.sh /opt/logs/backup.log 21这样第二天还能翻记录。调试技巧这块我三个工具轮流用。第一是bash -x script.sh它会逐行打印展开后的命令变量值一目了然适合定位逻辑问题第二是局部set -x和set x只在可疑代码段开启跟踪避免全程刷屏第三是shellcheck这个静态检查工具。我强烈建议每个脚本写完都跑一遍shellcheck script.sh它能在你不运行脚本的情况下告诉你哪里少了引号、哪里变量可能为空、哪里用了ls解析文件名等常见毛病。新手有它帮忙至少能躲掉八成低级坑。3.3 trap 信号捕获与临时文件清理脚本在执行过程中被打断是最容易被忽视的场景。用户按 CtrlC、系统重启、任务超时被 kill脚本都可能在任何一行突然死亡。如果脚本创建了临时文件或临时目录没人清理就变成垃圾残留。trap就是干这个的。最常用的绑定是 EXIT 信号脚本无论正常退出还是异常退出都会执行这段清理逻辑CLEANUP_FILES() trap rm -f ${CLEANUP_FILES[]} EXIT tmpfile$(mktemp) CLEANUP_FILES($tmpfile)用数组收集临时文件而不是无脑rm -rf是为了防止误删。你可以在脚本运行过程中随时往里追加文件最后统一清理。如果担心 CtrlC 时连清理都来不及跑再加一行trap echo 收到中断信号开始清理; exit 130 INT TERM这样遇到中断信号时先打一行日志再退出EXIT 陷阱会接着把临时文件清掉。这套组合我用了很久效果稳定建议你直接抄进自己的脚本模板里。4. 三个可直接开工的完整示例脚本4.1 日志归档清理工具先来一个最实用的日志目录按月份归档并清理 N 天前的过期归档文件。这个脚本我用了很多年替换了几个版本结构已经相当稳。#!/usr/bin/env bash set -euo pipefail LOG_DIR${1:-/var/log/app} ARCHIVE_DIR${2:-/data/log-archive} RETENTION_DAYS${3:-90} DRY_RUN${DRY_RUN:-0} log() { local level$1 shift printf [%s] [%s] %s\n $(date %Y-%m-%d %H:%M:%S) $level $* } archive_month() { local file month dest shopt -s nullglob for file in $LOG_DIR/*.log; do month$(date -d $(stat -c %Y $file) %Y%m) dest$ARCHIVE_DIR/$month mkdir -p $dest if [[ $DRY_RUN -eq 1 ]]; then log info 模拟归档: $file - $dest else mv -n $file $dest/ log info 归档完成: $file - $dest fi done } cleanup_old() { local f find $ARCHIVE_DIR -type f -name *.log -mtime $RETENTION_DAYS | while read -r f; do if [[ $DRY_RUN -eq 1 ]]; then log info 模拟删除: $f else rm -f $f log info 已清理过期归档: $f fi done } main() { log info 开始归档: 目录$LOG_DIR 归档$ARCHIVE_DIR 保留${RETENTION_DAYS}天 试运行$DRY_RUN archive_month cleanup_old log info 任务完成 } main $核心逻辑就三块。archive_month函数里stat -c %Y $file拿到文件的最后修改时间秒级时间戳date -d 时间戳 %Y%m转成202401这种月份字符串归档目录就按年月组织后续查找历史日志非常方便。mv -n的意思是“如果目标文件已存在则不覆盖”防止两个相同日期的日志互相覆盖。DRY_RUN试运行模式是我强烈建议保留的功能第一次跑脚本、或者要改策略时先开着试运行看一眼它准备干什么再真正执行。两点提醒date -d ...是 GNU coreutils 的语法Linux 系统没问题macOS 上要改用date -r或者装 coreutilsfind的结果用while read -r f处理而不是for f in $(find ...)原因还是防空格这个坑第五章专门说。4.2 批量重命名与权限修复脚本第二个示例来自一个真实需求某应用上传目录里混着.txt、.log和可执行文件每天需要整理一遍给.txt文件加日期后缀同时把脚本类文件统一修复为可执行权限。#!/usr/bin/env bash set -euo pipefail TARGET_DIR${1:?请指定目标目录} cd $TARGET_DIR shopt -s nullglob for f in *; do [[ -f $f ]] || continue if [[ $(basename $f) *.sh ]]; then chmod 755 $f else chmod 644 $f fi if [[ $f *.txt ]]; then base${f%.txt} new${base}_$(date %Y%m%d).txt if [[ $new ! $f ]]; then mv -n -- $f $new fi fi done开头TARGET_DIR${1:?请指定目标目录}用到了第二章讲的参数扩展没传参直接报错退出这是很典型的输入校验姿势。shopt -s nullglob的作用是如果目录里一个匹配都没有*.txt不会保留成一个字面字符串for 循环也不会空跑。mv -n -- $f $new里的--是为了防止文件名以-开头被误认为选项。这些细节单看都不起眼但加在一起脚本在真实环境里才扛得住。4.3 getopts 参数解析模板第三个示例更像一个模板我给自己所有“要上生产”的脚本都准备一份。它的核心是用getopts支持短选项比如-d 目录、-r 天数、-h 帮助告别靠$1、$2硬编码参数位置的写法。#!/usr/bin/env bash set -euo pipefail usage() { cat EOF 用法: $0 [选项] -d 指定日志目录 -r 保留天数 -v 显示版本 -h 显示帮助 EOF } VERSION1.0.0 LOG_DIR RETENTION_DAYS30 while getopts d:r:vh opt; do case $opt in d) LOG_DIR$OPTARG ;; r) RETENTION_DAYS$OPTARG ;; v) echo $VERSION; exit 0 ;; h) usage; exit 0 ;; *) usage; exit 1 ;; esac done if [[ -z $LOG_DIR ]]; then echo 错误: 必须指定 -d 参数 2 usage exit 1 fi echo 日志目录: $LOG_DIR, 保留天数: $RETENTION_DAYSgetopts的选项字符串d:r:vh里冒号表示该选项后面必须跟一个参数值。OPTARG是 getopts 内置变量存放选项后面的值。把参数解析独立成结构脚本瞬间就有“正规军”的感觉了。以后要继续加选项只需要在新 case 分支里加一行维护成本极低。5. 高级脚本的常见坑与排查经验速查5.1 管道子 Shell 与变量丢失这是 Shell 脚本最容易让老手都翻车的坑。你写了个循环统计文件行数#!/usr/bin/env bash count0 cat file.txt | while read -r line; do count$((count 1)) done echo 总行数: $count输出永远是总行数: 0。原因是管道符右侧的while循环在子 Shell 中执行循环里修改的count不会影响父 Shell 里的变量。管道一到结束子 Shell 的改动全没了。遇到这种问题换个思维方式解决——把输入重定向进循环而不是用管道count0 while read -r line; do count$((count 1)) done (cat file.txt) (...)这个进程替代语法让 while 在主 Shell 里运行变量修改就生效了。同理在find ... | while read ...里做的任何变量累加、数组追加循环结束后都会重置这是 Shell 新手强烈建议记住的一条铁律。5.2 定时任务环境与交互式环境的差异脚本在终端里手动跑一切正常放进 crontab 就失败是另一个高频事故。核心原因是 cron 执行任务时的环境极其简陋PATH 可能只有/usr/bin:/bin你手动安装的命令放在/usr/local/bin脚本里直接用python、docker到 cron 里就成了“command not found”。我的解决套路有固定三步。第一脚本头部显式设置 PATH比如export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin。第二脚本里所有外部依赖命令全部写全路径或者至少保证 PATH 里包含命令所在目录。第三cron 任务里统一用/bin/bash /opt/scripts/xxx.sh /var/log/xxx.log 21指定解释器并写日志。还有一条容易被忽略cron 的工作目录默认是用户家目录脚本里如果用相对路径读文件十个有八个会炸一律用绝对路径。5.3 文件名空格与 IFS 问题走进度最大的坑就是for f in $(ls *.txt)这种写法。$(ls *.txt)会先按空格把输出拆碎一个文件名my report.txt会被拆成my和report.txt两个词循环两次两次都报“文件不存在”。正确姿势是让 Shell 通配符自己去展开shopt -s nullglob for f in *.txt; do echo $f done这里 Shell 会把*.txt直接展开成完整文件名数组不会二次分词。另一个相关问题是 while read 循环里默认按空格切分行导致每行只有第一个单词被读进来。解决方法是while IFS read -r lineIFS 置空表示不做字段切分-r表示不把反斜杠当转义符。这两个细节是文件内容读取类脚本的救命稻草。5.4 排查速查表症状可能原因解决办法脚本中途莫名退出set -e遇到预期失败的命令用if分支或|| true兜底变量总为空变量在管道子 Shell 里被修改改用 (...)进程替代带空格文件名处理错乱for 循环里用了未加引号的$f所有变量展开都加引号$fcrontab 中命令找不到PATH 环境过简脚本头部显式 export PATH[[和[行为不一致语法使用错误优先使用[[ ]]使用未定义变量不报错缺少set -u脚本开头开启set -u这张表是我多年脚本事故的浓缩版建议你直接截图收藏。真正在现场排查时先看日志、再开bash -x、最后对照这张表绝大多数问题十分钟内能定位。6. 免费示例脚本的获取、落地与扩展建议6.1 脚本文件如何安全获取和校验这篇文章里的示例代码你完全可以当作免费脚本来使用——直接复制保存成.sh文件chmod x script.sh就能跑。如果是从其他地方下载的 Shell 脚本包我建议先做三件事再执行第一用shellcheck静态扫描一遍它能自动发现一大批隐患第二打开脚本把内容完整读一遍重点看有没有rm -rf、curl ... | sh、eval这类危险操作确保没有恶意代码第三小数据量试运营比如日志归档脚本先用一个月目录、两三份文件试跑确认行为符合预期。拿到压缩包后还可以用sha256sum计算校验值并对账。脚本文件是明文安全性核心在于阅读和审查不要因为它是“免费下载的”就盲目信任。6.2 落地三步走试运行、配置化、接任务再好的示例脚本直接搬进生产环境都是耍流氓。我落地一个脚本的标准流程是先开着DRY_RUN或echo模式试跑观察它打算执行哪些操作然后把跟业务相关的路径、天数、用户名全部提到脚本头部的变量或独立配置文件里最后写进 crontab 或 systemd timer。推荐用这样的目录结构组织你的脚本库/opt/scripts/ ├── bin/ │ ├── log_archive.sh │ ├── batch_rename.sh │ └── check_system.sh ├── lib/ │ └── common.sh ├── conf/ │ └── app.env └── logs/ └── scripts.loglib放公共函数库各脚本source ../lib/common.sh复用conf放配置脚本开头source ../conf/app.env加载。这样脚本参数不再硬编码在代码里换环境只改配置。6.3 免费示例的下一步扩展这四个示例脚本都不算终点给你几个值得动手的方向日志归档脚本可以升级为磁盘空间监控归档前检查分区使用率超过阈值自动告警批量重命名脚本可以加xargs -P并行处理上万文件场景性能提升明显如果想做到到期自动轮转清理把脚本挂到 systemd timer 比 crontab 管理更方便还能记录上次运行状态。我个人在实际使用中的体会是高级 Shell 脚本不是背语法背出来的是在一次次“脚本凌晨三点出问题你必须五分钟内定位”的真实场景里磨出来的。这些免费示例脚本我一直保持“打开就能改”的朴素风格因为脚本代码是给人维护的不是拿来炫耀技巧的。最后再多提醒一句不管你从哪里拿到一个示例脚本先跑一遍shellcheck再在最不重要的机器或目录上试运行一次。脚本这东西跑挂了最狼狈的永远是自己。