写 Shell 的人大概都经历过这样的阶段脚本刚开始只有十几行写起来很爽等需求一多同一个参数校验逻辑复制了五六遍日志打印散落四处哪天想改个输出格式得满文件找。这时候最自然的解法就是把重复逻辑抽成函数。Shell 编程里的函数没那么玄但也有不少反直觉的细节。这篇文章我会从定义语法、参数传递、变量作用域到实战案例再把常见坑整理一遍希望你看完可以直接拿回去用少走我当年走过的弯路。1. 为什么要在 Shell 里写函数解决的问题与适用场景1.1 没有函数的脚本维护起来有多痛苦我见过不少生产用的部署脚本两百多行没有函数全靠顺序执行重复代码块。最典型的就是参数判断if [ -z $1 ]; then echo 用法: $0 环境名 exit 1 fi这段代码在同一个脚本里出现了三次每次环境名、配置目录的判断逻辑都差不多但措辞略有差异。后来有人提了一个新需求参数为空时不仅要打印用法还要把当前支持的环境列表一起打出来。改起来就是满文件替换漏掉一处某个分支就静默出错。函数的意义不在于“代码量变少”而在于把逻辑收敛到一处后续只改一个地方。这是所有脚本语言通用的道理Shell 也不例外。1.2 函数、别名、独立脚本到底怎么选Shell 里实现复用有三种常见手段别名alias、函数、独立脚本。很多人分不清我平时是这么判断的。方式能否传参进程开销复用范围推荐时机alias只能简单拼接无当前用户交互环境单纯为了少敲几个字母函数支持标准参数无当前 shell、被 source 的库有逻辑判断、需要返回值或要在多脚本间共享独立脚本支持标准参数有新进程全局任何地方跨项目独立工具不需要回传变量给父进程别名的问题在于它本质上是个“文本替换”不适合在里面写 if/for更没法按参数去分支。独立脚本的问题是每次执行都要启动一个新进程虽然现代机器上性能影响可以忽略但它拿不到父 shell 里的变量想传回结果还得靠命令替换或者临时文件。函数在这两者之间取了平衡没有额外进程可以共享父 shell 的环境同时又支持完整的参数体系和条件逻辑。1.3 函数最常出现的三个位置第一个人环境配置文件比如~/.bashrc或~/.bash_profile这里放一些高频小工具函数比如extract解压各种格式压缩包、mkcd创建目录并进入。这些函数只服务于当前用户的交互式终端。第二独立脚本内部。脚本几十行以内可以直接顺序写一旦超过一百行我会按职责拆成 init、check_env、do_work、cleanup 这几类函数主流程保持简短。第三单独的函数库文件。比如项目里建一个lib/common.sh专门放日志、备份、异常处理这类通用函数其他脚本开头用source ./lib/common.sh导入。这种方式在多个脚本共享逻辑时非常省心我下面第 4 节的实战案例会用这种结构。2. 基础语法定义、调用、参数传递2.1 两种定义写法Shell 函数有两种等价的定义方式# 写法一function 关键字 function say_hello { echo Hello, $1 } # 写法二POSIX 风格推荐 say_hello() { echo Hello, $1 }两种写法在当前的主流 Bash 环境里行为完全一样。但如果你的脚本需要在不同的 sh 环境下跑写法二的可移植性更好因为function关键字是 Bash 的扩展而不是 POSIX 标准。我在自己项目的代码规范里统一用第二种。有个细节容易忽略函数定义只是把函数名登记到当前 shell 环境里并不会立刻执行。真正执行是在你写下say_hello world这一行的时候。所以哪怕函数定义在脚本靠后的位置只要调用发生在定义之后就行不必非得放在文件最前面。2.2 调用方式和位置参数细节函数调用和普通命令在形式上一样直接写函数名加参数中间用空格分隔。函数内部通过位置参数来访问这些参数print_args() { echo 函数名: $0 echo 参数个数: $# for arg in $; do echo 参数: $arg done } print_args a b c d这里有几个重要语义$0在函数内部依然指向当前脚本的名字而不是函数名。想拿到函数名本身Bash 里可以用$FUNCNAME。$表示所有参数$*也表示所有参数。两者在加了双引号后区别就出来了$会把每个参数都当作独立的词而$*会把所有参数拼成一个字符串。遍历参数时永远用$这是最不容易出错的习惯。$#是参数个数判断有没有传参、传参数量够不够时很常用。在函数内部处理完一部分参数后可以用shift把位置参数向左移动。比如第一个参数是命令名处理完shift之后剩下的$1就是命令的后续选项。这在写包装函数时特别有用。2.3 return 到底能返回什么Shell 函数的返回值是初学者最容易踩坑的地方因为它的语义和别的语言不一样。return只能返回一个 0 到 255 之间的整数用来表示状态码而不是返回一段计算后的数据。# 错误示范想把字符串传出去 get_name() { return abc # 报错数值太大 } # 正确做法结果输出到标准输出 get_name() { echo report_$(date %F).log } filename$(get_name)大多数情况下逻辑是这样的需要给调用方传复杂数据时用echo打到标准输出调用方用$(函数名)接住需要传状态时才用return。比如check_config() { if [ -f $1 ]; then return 0 else echo 找不到配置文件: $1 2 return 1 fi } if check_config /etc/app.conf; then echo 配置文件存在 else echo 检查失败 fireturn 0表示成功任何非零表示失败。调用函数后$?会记录最近一次函数调用的返回码但这个变量很脆弱任何一条命令执行都会覆盖它所以需要立即判断或保存。2.4 函数名与外部命令冲突函数名是可以和外部命令同名的。比如你写了一个ls函数在当前 shell 里执行ls会优先走到你的函数而不是系统的ls命令。利用这个特性可以做“增强版命令”但一定要小心里面的递归问题ls() { command ls -lh $ }上面的command关键字是一条逃生通道它告诉 Bash 后面的命令按“外部命令/内建命令”的正常路径去找不要再触发同名函数。没有command的话你的ls函数内部又调用ls就会无限递归到栈溢出。这算是我见过的比较隐蔽的卡死场景。3. 变量作用域与进阶技巧3.1 local 与全局变量Shell 函数里的变量默认是全局的。哪怕你没有显式声明函数里随便写resultchanged函数结束后这个result还是存在调用方能看到。这在某些场景是特性但多数时候是隐患。count_files() { local count0 for f in $dir/*; do if [ -f $f ]; then count$((count 1)) fi done echo $count }用local声明局部变量函数结束变量就消失不会污染全局命名空间。我写函数的第一原则就是所有临时变量一律local需要对外暴露结果时用echo返回除非调用双方有明确的约定要共享全局变量。这里有个小知识local只能在函数内部使用在脚本顶层直接用会报错。如果你的 Bash 版本较新也可以用declare -g varvalue显式声明一个全局变量但我在早期兼容性要求高的脚本里会尽量避免。3.2 默认值参数与参数校验Shell 的参数展开语法很强大常用:-来设置默认值connect() { local host${1:-127.0.0.1} local port${2:-3306} echo 连接 ${host}:${port} }${1:-默认值}的意思是当$1未设置或者为空时使用默认值。与之相似的${1-默认值}只在变量完全未设置时生效$1传了空字符串会保留空字符串这个细微差别我经常提醒自己。想要强制必填参数可以用${2:?错误信息}deploy() { local env_name${1:?用法: deploy 环境名} echo 开始部署到 $env_name }如果调用时没有传参数Shell 会直接打印错误信息并从函数返回非零状态省得你写一大段 if 判断。参数校验除了数量还要检查内容。比如端口号就得判断范围connect() { local port${1:?必须提供端口号} if ! [[ $port ~ ^[0-9]$ ]] || [ $port -lt 1 ] || [ $port -gt 65535 ]; then echo 非法端口号: $port 2 return 1 fi echo 连接端口 $port }[[ ~ ]]是 Bash 的正则匹配语法比用grep判断更直接也不产生额外的子进程。3.3 递归函数与间接调用Shell 函数支持递归虽然是脚本语言写递归时心里要惦记着性能但简单场景完全可接受。一个比较实用的例子是递归列出目录树show_tree() { local prefix$1 local path$2 for item in $path/*; do [ -e $item ] || continue local name${item##*/} if [ -d $item ]; then echo ${prefix}${name}/ show_tree ${prefix} $item else echo ${prefix}${name} fi done } show_tree /tmp/demo递归的终止条件通常是路径不存在或目录内容为空。上面[ -e $item ] || continue是为了处理空目录的情况否则$path/*展开成一个字面量通配符会报错。“函数名作为参数”也是常见需求。比如做一个菜单式的分发器do_start() { echo 启动服务; } do_stop() { echo 停止服务; } do_restart() { do_stop; do_start; } dispatch() { local action$1 case $action in start) do_start ;; stop) do_stop ;; restart) do_restart ;; *) echo 未知操作: $action 2; return 1 ;; esac } dispatch restart这种写法让主流程变成一张清晰的分发表加新命令只需要多写一个函数和一个 case 分支。3.4 管道与子 shell 的怪癖Shell 函数里最容易出现“变量没变”错觉的场景就是管道。看下面的例子count_lines() { local total0 cat $1 | while read -r line; do total$((total 1)) done echo 总行数: $total } count_lines /tmp/data.txt你期待输出总行数实际输出的很可能是 0。原因是管道的右侧while循环部分实际上运行在一个子 shell 里total的修改发生在子 shell 内部父 shell 里的同名变量完全没动。解决方式有几种。最简单的是把整个过程放到一个命令组里让计数逻辑和输出逻辑在同一个进程中完成count_lines() { local total0 { while read -r line; do total$((total 1)) done $1 echo 总行数: $total } }这里改成输入重定向[ -d $item ]而不是管道让while循环在函数所在的进程里执行变量修改才能保留下来。另一个做法是使用进程替换count_lines() { local total0 while read -r line; do total$((total 1)) done (cat $1) echo 总行数: $total }进程替换(...)把命令输出伪装成一个临时文件循环在这个临时文件上读取仍然在父 shell 进程里执行。这个语法初看有点怪但用多了会非常顺手。4. 实战案例三组可以直接复用的函数4.1 日志输出函数写脚本没有标准库日志打印是最容易“各写各的”的地方。我自己维护一个lib/log.sh里面只有几行但项目里所有脚本都靠它保持一致。# 日志级别0DEBUG 1INFO 2WARN 3ERROR LOG_LEVEL${LOG_LEVEL:-1} log_debug() { [ $LOG_LEVEL -le 0 ] echo [DEBUG] $(date %F %T) $* 2; } log_info() { [ $LOG_LEVEL -le 1 ] echo [INFO ] $(date %F %T) $* 2; } log_warn() { [ $LOG_LEVEL -le 2 ] echo [WARN ] $(date %F %T) $* 2; } log_error() { [ $LOG_LEVEL -le 3 ] echo [ERROR] $(date %F %T) $* 2; }注意每个函数都把日志输出重定向到标准错误2。这个习惯非常关键脚本的标准输出往往被用来传递数据比如执行scripts/run.sh log_info 开始如果把日志打到标准输出日志内容就会掺进数据流里污染命令替换的结果。凡是给人看的进度、警告、错误信息一律走标准错误。使用的时候先 source 再调用source /path/to/lib/log.sh deploy() { log_info 开始部署 if ! build_project; then log_error 构建失败 return 1 fi log_info 部署完成 }如果哪天想把日志同时写到文件和控制台只需要把一个日志文件的重定向路径设计好或者用tee中间接一下函数体的其他调用处都不用动。4.2 带校验的环境准备函数部署类脚本最常见的需求是先检查依赖命令是否齐全缺一个就立刻报错退出。我把检查逻辑抽成require_command一劳永逸。require_command() { local cmd$1 if ! command -v $cmd /dev/null 21; then echo 缺少必需命令: $cmd 2 return 1 fi } prepare_env() { local commands(git make gcc) local cmd for cmd in ${commands[]}; do require_command $cmd || return 1 done echo 环境检查通过 } if ! prepare_env; then echo 环境准备失败请先安装依赖 2 exit 1 fi这个函数有几个值得注意的细节。command -v和which的区别在于which是外部命令在一些发行版上不存在而且它不一定能识别 Shell 函数和内建命令command -v是 Shell 内建的查找机制能覆盖命令、函数、内建命令、别名。判断某个命令是否可用command -v是最可靠的方式。 /dev/null 21把正常的路径输出和错误输出都丢弃我们只关心退出码。这又是一个“输出和状态分离”的例子要的是状态输出就别留着。4.3 配置文件备份与修改函数凡是脚本里要动配置文件我都强烈建议先备份。写一个通用的备份函数返回备份文件的路径调用方非常省心backup_file() { local src$1 local suffix$(date %Y%m%d%H%M%S) local dst${src}.${suffix}.bak if [ ! -f $src ]; then echo 备份失败文件不存在: $src 2 return 1 fi cp -a $src $dst echo $dst }使用方式modify_config() { local conf/etc/app/config.ini local bak bak$(backup_file $conf) || return 1 # 修改配置这里模拟替换一行 sed -i s/^timeout.*/timeout30/ $conf echo 已修改配置备份位于: $bak }这里又用到了命令替换捕获函数输出bak$(backup_file $conf)。如果备份失败函数返回非零命令替换后立即|| return 1整个操作不会往下继续。这种风格我写多了以后已经成了条件反射凡是函数可能失败的调用处就接||显式处理避免脚本在出错后继续乱跑。5. 常见问题排查与经验速查5.1 排查工具箱函数出问题的时候先别急着改代码用下面这些手段快速定位。type 函数名会显示函数的完整定义也会告诉你它是别名、函数还是外部命令。这是我排查“为什么我定义的东西没生效”的第一把钥匙。declare -f 函数名只输出指定函数的定义。配合declare -F可以列出当前 shell 里所有已定义的函数名。bash -n 脚本名语法检查不会真正执行适合在跑之前先排除低级语法错误。set -x在调用函数前开启它会逐行打印会实际执行的命令及展开后的参数看完再用set x关掉。排查“参数传错了”或者“某个变量为空导致命令变形”时效果极好。set -u变量未设置即报错。在函数里一旦写错变量名它能第一时间暴露出来避免把空值当成有效值往下传。一个比较实用的组合是set -x deploy staging set x输出会非常啰嗦但往往一眼就能看到问题出在哪一行。排查完记得关掉否则后面所有正常日志都会被淹没。5.2 问题与解决对照表我把实际工作中见过的、朋友问过的问题整理成了表格按“现象”来找“原因”和“解法”。现象原因解决办法调用函数时报 command not found函数定义所在的文件没有被 source或函数定义写在子进程里先source 库文件用type 函数名确认定义是否可见return 1后调用方没拿到状态$?在函数调用后被其他命令覆盖调用后立刻用if判断或先local code$?保存echo输出的内容没被捕获函数内部其他命令也往标准输出打印把注释、提示信息改为2标准输出只留给真正的结果管道里的变量赋值后调用方看不到管道各段运行在子 shell用进程替换 (命令)或改为输入重定向函数名和系统命令重名导致递归函数优先级高于 PATH函数内部用到同名命令时加command前缀set -e下函数一有非零状态脚本就退出set -e遇到未处理的失败状态直接退出在函数内显式 source 之后修改函数定义不生效当前 shell 内存里还是旧定义修改后重新source新开终端也行5.3 我踩过的几个坑第一个坑也是最经典的echo和return混用。早期写函数时我想返回一个字符串直接写了return 文本结果报错。后来知道return只管状态码数据走echo两个通道要分开用。更深一层的坑是如果函数里既想输出日志又想输出真正的结果日志会把结果搞脏。所以我现在只要有 getter 风格的函数一律把日志重定向到2标准输出干干净净只给结果。第二个坑是 source 和执行的混淆。我一度直接在命令行跑bash mylib.sh测试库文件结果函数定义全在子 shell 里跑完就没了。库文件必须用source或.来加载让定义落到当前 shell后面才能直接用。第三个坑和调试有关。开了set -e之后函数里某个命令返回了非零状态脚本会直接退出而且退得很突然往往看不出是哪个函数、哪一行。后来我养成了两个习惯函数内部每个可能失败的关键命令都显式写清失败处理比如cmd || return 1调试阶段临时开set -x看是哪一行触发的退出。这两个组合拳基本能解决绝大多数莫名其妙的提前退出问题。第四个坑是空目录和通配符。在函数里写for item in $path/*如果目录是空的这个模式串不会展开成文件列表而会原样保留一个带星号的字符串传给循环体。我在一个递归列目录函数里就是因为这个差点把星号当成了文件名处理。现在的习惯是循环体里先做[ -e $item ] || continue把不存在的路径过滤掉再继续处理。我个人在实际操作中的体会是Shell 函数不难写难在把所有“进程边界”和“输出通道”想清楚。函数在当前 shell 执行还是子 shell 执行标准输出是数据还是日志return 是状态还是数据这三件事想明白了Shell 函数的七成坑就都绕开了。等这些细节成了肌肉记忆你会发现自己写脚本的速度和信心会明显不一样。如果你在公司或项目里有自己积累的公共函数库建议也整理成一篇文章或文档方便团队其他人直接复用而不是各自重写第三遍同样的逻辑。