刚接触Shell那会儿我总觉得写脚本就是“把命令排成队”跑通一次就完事。等真正开始维护线上环境才发现这种习惯特别坑一段脚本只要换台机器、换个参数或者某个中间步骤出点小问题排查起来耗掉的时间比重写还多。后来我意识到Shell脚本从“能跑”走向“能维护能复用能快速定位故障”关键就卡在三件事上函数、数组和脚本调试。这篇文章我就围绕这三块把我实际项目里积累的经验、踩过的坑以及完整的排查思路整理出来。适合已经会写基本Shell语法但想把脚本做成正经工具的开发者、运维和自动化工程师参考。1. 函数化改造别再用“复制粘贴”堆脚本1.1 函数定义与调用先搞清楚“调用前定义”这个底层逻辑Shell函数的定义有两种写法function my_func { echo hello } my_func() { echo hello }我习惯用第二种不带function关键字原因是可读性好而且在sh、bash、dash之间的兼容性都稳定。注意Shell是逐行解释执行的函数必须先定义再调用。你可以把整个脚本想象成一个从上往下翻的笔记本解释器翻到调用行时必须在前面已经记下了这个函数的名字否则直接报command not found。一个最基础但非常实用的封装是日志函数。我几乎每个脚本里都会放一个log() { local level$1 local msg$2 echo [$(date %Y-%m-%d %H:%M:%S)] [$level] $msg }这样后续任何地方想打印信息直接log INFO 备份开始就行格式统一改样式也只动一处。这里面的local关键字很关键它把变量限制在函数内部不会污染全局命名空间。Shell里的函数没有自己的变量域如果不加local函数里随便写个变量名脚本其他地方就会悄悄多出一个全局变量这种隐形的耦合最容易在后期出问题。1.2 参数处理$1、$#、shift与默认值函数内部和脚本主体一样位置参数都是$1、$2这样的形式数量超过9个时用${10}。$#表示参数个数$表示所有参数这个组合是遍历参数的标准动作print_params() { echo 参数个数: $# for p in $; do echo 参数: $p done }这里有个必须强调的细节在双引号内$和$行为完全不同。$会把每个参数当成独立个体逐个传递即使某个参数本身带空格也不会被拆开$则是把所有参数捏成一个字符串按IFS里的第一个字符拼接。绝大多数情况下你应该用$否则带空格的参数就是你脚本里的第一颗定时炸弹。shift命令也是处理参数的高频操作它的作用是让位置参数集体左移默认一次移一位。最典型的场景是手写命令行参数解析parse_args() { while [ $# -gt 0 ]; do case $1 in -f|--file) file$2 shift 2 ;; -v|--verbose) verbose1 shift ;; -h|--help) usage exit 0 ;; *) echo 未知参数: $1 2 exit 1 ;; esac done }shift 2的意思是连参数值和它的值一起移走避免下一轮循环把-f的值当成新的$1。参数取默认值用${2:-默认值}冒号加横线表示“如果变量没设置或者是空字符串就用后面的值”。1.3 返回值陷阱为什么你的return总是拿不到结果新手最容易踩的坑就是把函数当成普通编程语言的return来用get_name() { local namehello shell return $name # 错误 }return语句在Shell里只能返回退出码取值范围是0到255的整数0表示成功非0表示各种失败状态。想返回字符串正确的做法是往标准输出打然后调用方用命令替换接住get_name() { echo hello shell } result$(get_name)$?里保存的是上一条命令的退出码但它是个一次性的东西紧接着执行任何一条命令都会覆盖它所以要么立即判断要么先存进变量。命令替换还有一个我非常想提醒的细节变量赋值的退出码不一定是函数里的退出码。比如local result$(func_with_fail)local这个内置命令永远返回0会把你辛辛苦苦在函数里设置的退出码吞掉。所以脚本里想判断“如果函数失败就退出”时别写成local result$(func)先写函数调用再local接收或者分开两步。这也是我在真实代码里排查了很久才发现的明明函数返回了1if判断却永远成立。1.4 函数库把公共逻辑抽成独立文件脚本多了之后日志函数、配置解析函数、发通知的函数基本每个脚本都要一份。复制粘贴是最差的方案正确做法是把公共函数放到一个单独文件里调用方通过source等价于点号.引入# lib/common.sh log() { ... } send_alert() { ... }# deploy.sh source $(dirname ${BASH_SOURCE[0]})/lib/common.sh log INFO 开始部署这里有个大坑我必须单独拎出来说不能用$(dirname $0)来定位脚本文件所在目录。$0是脚本本身的名称这在脚本被直接执行时没问题但被别的脚本source时$0依然指向外层那个脚本路径就成了别人的路径。正确做法是${BASH_SOURCE[0]}这是bash专门提供用来表示“当前这个源文件路径”的变量。库文件里还有个需要注意的点source一个文件等于把它里头的顶层代码原样执行一遍。所以公共函数库里别放裸露的命令行代码否则每次source都会重复执行。一个很实用的技巧是在库文件末尾加个判断if [[ ${BASH_SOURCE[0]} $0 ]]; then main fi这样这个库文件既能单独运行做自测又能被其他脚本安全引入两不误。2. 数组实战从“索引列表”到“键值映射”2.1 数组基础创建、追加、长度、切片与读取很多写惯了Python或JavaScript的人总觉得Shell数组不好用其实它的能力被严重低估了。基础操作一条条过# 创建 apps(nginx mysql redis) # 单个元素 echo ${apps[1]} # 输出 mysql # 所有元素注意引号 echo ${apps[]} # 数组长度 echo ${#apps[]} # 追加 apps(kafka) # 切片从第1个开始取2个 slice(${apps[]:1:2}) # 删除单个元素 unset apps[1] # 删除整个数组 unset apps反复强调双引号的原因还是那个空格问题。${apps[]}不加引号时数组里某个元素带空格就会被拆成多个词加上引号${apps[]}每个元素才作为一个完整整体。这个细节直接决定你的脚本在文件名带空格的环境下是稳还是炸。2.2 遍历数组与“空格分词”的经典冲突我最常看到的问题写法是这样的for file in $(ls *.txt); do echo $file done一旦文件名里有空格for循环就会把my file.txt拆成my和file.txt两个词。这就是典型的命令替换分词问题和数组本身无关但坑起来一模一样。正确的批量文件遍历姿势是用数组接住find输出再逐元素处理。注意find输出最好用while read方式while IFS read -r file; do process $file done (find /data -name *.log -type f)IFS是为了让read保留每行前后的空白字符-r是让read不要把反斜杠当转义符。这里的进程替换 (...)能保证整个循环在当前shell环境里执行如果你写成管道find | while read循环体内设置的变量会在管道结束后消失因为那部分跑在子shell里。这个问题我当年排查过很久变量明明打出来了退出循环就成空根源就在子shell。数组在批量任务里的威力很大比如要并发重启一批服务可以把服务名放进数组逐个循环处理。如果数据来自文件还有一个非常实用的内置命令readarray也叫mapfilereadarray -t ip_list ./ips.txt-t参数会去掉每行末尾的换行符一次搞定“文件按行转数组”的需求。Windows编辑过的文件可能带\r读进来元素尾部会多个回车可以先sed -i s/\r$//处理一下这个细节不贵但很省事。2.3 关联数组让脚本拥有配置表bash从4.0开始支持关联数组相当于给Shell加了键值对数据结构。使用前一定要先声明否则bash会把它当普通索引数组处理declare -A service_port service_port( [nginx]80 [mysql]3306 [redis]6379 ) echo ${service_port[nginx]} # 80遍历键值时键集合是${!map[]}for svc in ${!service_port[]}; do echo $svc - ${service_port[$svc]} done关联数组最典型的应用是解析配置文件。比如一个简单的properties风格文件timeout30 retry5 debugtrue可以很轻松地读进关联数组declare -A config while IFS read -r key value; do key$(echo $key | tr -d ) config[$key]$(echo $value | tr -d ) done app.properties注意这里用IFS指定分隔符避免value里包含等号被误拆。关联数组的遍历顺序是随机的内部用哈希表存储如果你需要确定性输出先把键集合排序再遍历for key in $(echo ${!config[]} | tr \n | sort); do ... done2.4 传数组给函数引用传递与副本传递的取舍数组没法像字符串那样直接作为参数传进函数常见的两种方案有明确的取舍。第一种把数组展开成位置参数传进去。func() { local items($) echo 元素个数: ${#items[]} } arr(apple banana cherry) func ${arr[]}这个方案简单直观代价是数组被拷贝了一份。如果数组很大或者函数里要修改数组内容并让外部生效就不合适。第二种bash 4.3以上支持nameref也就是名字引用可以真正把数组引用传进函数func() { local -n arr_ref$1 echo 第一个元素: ${arr_ref[0]} arr_ref[1]modified # 能直接改外部数组 } my_arr(a b c) func my_arr函数内声明local -n arr_ref$1后arr_ref就成了外部变量my_arr的别名里面对数组的修改会直接作用到外部。这个能力在写排序、过滤这类需要原地修改数组的函数时非常顺手。最后必须提一个set -u下的经典坑脚本开了-u选项未定义变量报错后如果对空数组做${arr[]}展开bash会报unbound variable直接中断脚本。解决办法是给展开加个保护if [ ${#arr[]} -gt 0 ]; then for item in ${arr[]}; do ... done fi或者用我项目里常用的兜底写法${arr[]${arr[]}}这个写法在数组为空时不触发未定义变量的报错实打实救了不知道多少回。3. 脚本调试从盲人摸象到逐步定位3.1 静态检查先行bash -n与shellcheck调试的第一层防线不是加打印而是静态检查。bash本身提供语法检查bash -n script.sh只解析不执行语法有硬伤会直接报出来。但这只能抓语法错误抓不了逻辑问题所以我的习惯是再跑一次shellcheck。这个开源工具几乎是每个Shell脚本项目的标配安装方式# Debian/Ubuntu apt install shellcheck # CentOS/RHEL yum install ShellCheck # macOS brew install shellcheck运行起来就是一条命令shellcheck script.sh它会输出一段类似编译器警告的信息比如最常见的SC2086变量没加双引号。很多看起来“跑得不错但偶尔翻车”的脚本用shellcheck扫一遍都能照出病根。我把shellcheck纳入我的常规流程后找bug的时间至少少了一半。3.2 xtrace模式set -x与PS4定制输出静态检查通过之后真正跑起来排查逻辑时xtrace模式是最强大的武器。执行时打开bash -x script.sh或者脚本内部局部开启set -x # 需要观察的代码段 set xset -x打印的是每条命令完成变量展开后的真实执行内容和set -v打印原始输入行不同你能看到变量到底被替换成了什么。默认的调试前缀是跟两三个层级的函数调用后光看号根本分不清哪行是谁打印的。所以实际干活时我几乎都会定制PS4export PS4 [${BASH_SOURCE}:${LINENO}] ${FUNCNAME[0]:函数:${FUNCNAME[0]}} bash -x script.sh这样每一行调试输出都带上了源文件、行号和所在函数名排错思路会清晰非常多。跑出来的调试输出量可能很大建议把锯齿流写入文件再集中分析bash -x script.sh 2 trace.log3.3 set -e、set -u、set -o pipefail的取舍与陷阱这三个选项是Shell脚本工业化的标准组合但实际用起来的细节比表面复杂得多。脚本开头我通常会写set -uo pipefailset -u遇到未定义变量就报错能防变量名拼写错误这类无声bug。set -o pipefail管道中任何一个命令失败整条管道的返回码就记为失败避免“前面已经出错了后面照常执行还返回成功”的假象。但set -e我很少无条件开启原因是它的行为有不少反直觉的地方。举例来说set -e if [ -f /tmp/x ]; then echo 存在 fi即使[ -f /tmp/x ]执行结果是非零set -e也不会直接退出因为它位于if判断的条件位置这种“被检查的失败”是允许的这个设计是合理的。但过分依赖set -e会带来另一个问题它只对“没被检查”的错误生效一旦你写成cmd1 cmd2或cmd1 || cmd2set -e就半失效了。再加上函数内set -e的行为会受到调用环境影响经常出现“直接跑脚本崩溃了放函数里调用却没事”这种怪象。我的建议是生产脚本里显式处理错误路径别指望set -e兜底。关键的命令后面可以加类似这样的检查if ! backup_db; then log ERROR 数据库备份失败 exit 1 fi如果脚本里某个命令确实“失败也没关系”用set e临时关掉执行完再set -e开回来比用|| true隐晦地吞错误要更明确。关于pipefail也要留个心眼。管道上游命令如果因为下游提前关闭而收到SIGPIPEpipefail同样会判管道失败。最典型的是命令进程的文件流输出管道给head之类截断场景set -o pipefail yes | head -n 1 # 返回码是141yes被管道破裂信号干掉了这种“假失败”排查起来很绕知道原理看到141就不慌。3.4 常见坑定位案例为什么同一段命令在终端能跑定时任务里却找不到命令调试这节没有实战案例说不过去。我有一个印象很深的问题也是很多运维新手会撞上的一个脚本在终端里手动执行完全正常一旦放进crontab定时任务就开始疯狂报command not found。第一次遇到的人往往摸不着头脑。其实根因几乎都是PATH环境变量不同。终端登录时会加载/etc/profile等文件把/usr/local/bin这类目录加进PATH而cron执行时PATH通常被精简成/usr/bin:/bin脚本里用到的/usr/local/bin下的命令自然全部找不着。排查链路是这样走的# 1. 手动执行脚本加xtrace观察 bash -x script.sh # 2. 在脚本里打印当前PATH echo PATH$PATH # 3. 对比cron环境里的PATH在cron执行的命令里打印 # */1 * * * * echo PATH$PATH /tmp/cron_path.log答案一目了然。解决方式要么在脚本里显式声明需要的PATH要么用命令的绝对路径比如/usr/local/bin/restic要么脚本开头就export PATH/usr/local/bin:/usr/bin:/bin。我推荐前两种因为直接把PATH写死在脚本里换机器又可能要改。顺带一提诊断“命令找不到”类问题也可以用type和command -v在脚本里做健康判断for cmd in curl jq python3; do if ! command -v $cmd /dev/null 21; then echo 缺少依赖命令: $cmd 2 exit 1 fi done另外提醒一句网上有些教程会把curl下载脚本和管道执行堆在一起甚至鼓励直接curl管道给bash来运行见到这种操作要格外警惕尤其是里面出现可疑的下载远程脚本再执行的行为时不要盲目照跑。我自己遇到不明来源的脚本第一件事是先下载到本地打开看看内容确认每一步在做什么再执行。3.5 trap钩子DEBUG、ERR、EXIT的实战用法trap是调试和异常处理的神器。三大信号对应三类场景# 每条命令执行前触发一次 trap echo 执行: $BASH_COMMAND DEBUG # 任何命令返回非零时触发 trap echo 出错位置: 文件${BASH_SOURCE}, 行号${LINENO}, 命令${BASH_COMMAND} 2 ERR # 脚本退出时触发适合清理动作 trap rm -f $TMP_FILE EXIT我最常搭配的是ERR和EXIT#!/bin/bash set -uo pipefail TMP_FILE$(mktemp) trap rm -f $TMP_FILE EXIT trap echo 异常退出见位置: ${BASH_SOURCE[0]}:${LINENO} 2 ERR # 业务逻辑...这样哪怕脚本中途因为意料之外的错误直接退出临时文件也能保证被清掉不会在服务器上留下垃圾。DEBUG trap打印$BASH_COMMAND相当于一个“每条命令执行前自动打印”配合PS4做日志低配版追踪也很有用。4. 综合实战一个可复用的服务健康检查脚本4.1 需求分析与结构设计函数、数组、调试学完得连起来用一次。我的示例场景是一台服务器上跑着多个手工维护的服务团队成员时不时改配置改了之后服务可能就悄悄挂了。人工查太累我写一个健康检查脚本收集哪些服务进程在不在、关键端口通不通最后输出一份整洁的报告。设计时用到的核心点关联数组存服务和端口的对应关系方便按服务名取端口。函数封装检查逻辑check_service、check_port、main各干各的。脚本内部保留调试开关遇到问题可以随时开跟踪。4.2 完整脚本与逐段注释#!/bin/bash set -uo pipefail SCRIPT_DIR$(cd $(dirname ${BASH_SOURCE[0]}) pwd) DEBUG_MODE${DEBUG_MODE:-0} if [ $DEBUG_MODE 1 ]; then PS4 [${BASH_SOURCE}:${LINENO}:${FUNCNAME[0]}] set -x fi declare -A SERVICES( [nginx]80 [mysql]3306 [redis]6379 [app]8080 ) log() { local level$1 shift echo [$(date %Y-%m-%d %H:%M:%S)] [$level] $* } check_process() { local name$1 if pgrep -x $name /dev/null 21; then return 0 fi return 1 } check_port() { local port$1 if ss -tln | grep -q :$port ; then return 0 fi return 1 } report_line() { local svc$1 local port$2 local statusOK local reason进程和端口都正常 if ! check_process $svc; then statusFAIL reason进程不存在 elif ! check_port $port; then statusFAIL reason进程在但端口未监听 fi printf %-10s %-20s %-8s %s\n $svc 端口:$port $status $reason } main() { local failed0 echo 服务健康检查报告 $(date %F %T) for svc in ${!SERVICES[]}; do report_line $svc ${SERVICES[$svc]} check_process $svc || failed1 if ! check_process $svc; then failed1; fi done echo if [ $failed -eq 0 ]; then log INFO 所有服务正常 else log ERROR 存在异常服务 exit 1 fi } main这段代码里包含几个我特意设计进去的点set -uo pipefail保证变量拼错能暴露、管道失败不会被吞。DEBUG_MODE环境变量控制是否进入跟踪模式线上排查时DEBUG_MODE1 ./check.sh就能看到完整执行路径。report_line函数里把进程检查和端口检查分开原因是我见过很多服务进程明明僵死着端口还占着单独看进程或者单独看端口都发现不了问题。4.3 进阶技巧并行检查、输出着色、日志轮转这个脚本最简单的版本是串行检查服务数量多了之后可以并发提速。Shell里做并发不需要高级工具后台运行加wait就够了for svc in ${!SERVICES[]}; do check_one $svc ${SERVICES[$svc]} done wait注意并发输出会互相交织解决办法是每个子任务先把结果写到独立临时文件wait之后统一读取。临时文件名里带上进程ID避免冲突TMP_DIR$(mktemp -d) for svc in ${!SERVICES[]}; do ( report_line $svc ${SERVICES[$svc]} ) $TMP_DIR/$svc.result done wait cat $TMP_DIR/*.result输出着色能让人一眼扫到异常项。判断当前输出是不是终端是才上色否则把颜色代码收掉避免重定向到日志文件里留下一堆转义序列if [ -t 1 ]; then RED$(tput setaf 1) GREEN$(tput setaf 2) RESET$(tput sgr0) else RED GREEN RESET fi日志轮转的思路简单脚本每次运行先把上一次的报告归档再保留最近N份。不必一上来就引入logrotate脚本自己处理也可以REPORT_DIR$SCRIPT_DIR/reports mkdir -p $REPORT_DIR cp $REPORT_DIR/current.txt $REPORT_DIR/$(date %Y%m%d_%H%M%S).txt 2/dev/null || true ./check.sh $REPORT_DIR/current.txt find $REPORT_DIR -name *.txt -mtime 7 -delete4.4 工程化自查清单脚本要拿去给别人用我会先过一遍这张清单都是这些年踩坑踩出来的语法静态检查bash -n shellcheck跑一遍警告清零。头部选项set -uo pipefail按需开启set -e慎用。所有变量展开都加了引号数组用${arr[]}。关键命令的失败有显式判断不依赖“碰巧退出码正确”。路径用绝对路径或者基于${BASH_SOURCE[0]}解析不依赖$0。脚本里所有外部命令在部署机上存在缺了有提示。临时文件写在mktemp创建的目录下且配了trap EXIT清理。脚本重复执行不会产生副作用。输出在非终端场景下不带颜色日志里不会有乱码。预留了DEBUG开关线上出问题可以现场开跟踪。这套流程走完基本上一个脚本从“我机器上能跑”升级成“别人机器上也稳”。最后再分享一个小习惯。我写Shell脚本超过40行就会强制自己拆函数超过100行就想是不是该用更高级的语言了。Shell真正的舒适区是把系统命令组织成自动化流程函数和数组是它写优雅、写安全的基础调试手段则是遇到故障时不慌的底气。掌握这三样日常脚本的基本盘就已经很稳了。