Shell脚本在很多程序员眼里是“胶水语言”但在真正的运维和DevOps场景里它几乎是基础设施一样的存在。而排在Shell编程规范第一位的往往是变量——因为变量用不好脚本八成要出问题。这篇文章不打算讲那些花里胡哨的语法糖而是想把Shell编程规范和变量这两件事掰开揉碎说说实操中最常见的习惯、坑和原则。如果你是刚准备入门Shell的新手或者写过一阵子脚本但总觉得风格别扭、莫名踩坑的老手这篇应该对你都有用。1. 为什么较真“编程规范”这件事1.1 Shell脚本的典型应用场景Shell脚本这玩意看起来简单但在实际工作中几乎无处不在。我做了这么多年运维和自动化总结下来Shell脚本最常用的场景大概是这几类批量部署与初始化几十台服务器要装同一套环境手动一台台敲命令不现实。写个脚本用循环挨个处理几分钟搞定。定时任务与日志清理日志天天涨磁盘说满就满。用crontab配合一个几十行的Shell脚本定期压缩、清理比装一堆监控工具轻量得多。CI/CD流水线现在虽然是容器的天下但很多构建、测试、发布环节里Shell仍然是串联一切的“胶水”。GitLab Runner、Jenkins里最常见的构建脚本就是Shell。数据处理与文本解析awk、sed、grep这些命令组合起来处理日志、配置文件简直是神器。很多Java、Go程序员也会在服务器上临时写一段Shell来处理问题。你会发现不管你在什么技术栈里只要碰Linux服务器就绕不开Shell。而Shell脚本写得好不好首先就看变量用得好不好。变量是整个脚本的数据中枢命名混乱、引用错误、作用域失控脚本跑起来就是一场灾难。1.2 没有规范的下场真实踩坑经历我接手过一个项目的部署脚本那脚本能用但里面全是“飞线”。变量名从a到z都有有的地方用temp存路径有的地方用tmp存临时文件名函数里改了全局变量外面也被带跑字符串判断时变量不加引号遇到带空格的文件名就直接崩。最典型的一次脚本里有句if [ $status ok ]结果$status是空字符串时命令展开成了if [ ok ]直接报unexpected operator。要是提前规范成if [[ $status ok ]]哪来这些破事还有个更隐蔽的坑有人图省事把变量命名成PATH或者HOME结果不小心把系统环境变量覆盖了。后面命令全找不着了因为PATH被改成一个普通字符串ls、cp、sed全都command not found排查起来血压直接拉满。所以我后来养成了一个习惯写脚本的第一件事就是先把规范立起来。哪怕是一个临时脚本也要按长期维护的标准来写。因为你永远不知道这个“临时脚本”会不会用三年。2. 变量是Shell最核心的“数据管线”2.1 变量定义与引用的基础规则Shell变量定义有个特别容易踩的坑等号两边不能有空格。很多从Java、Python转过来的新手习惯写成name zhangsan结果Shell直接把它当成执行命令name后面跟俩参数报command not found。正确写法是namezhangsan age18而且注意Shell变量默认全是字符串哪怕你赋个数字它也是字符串。运算的时候需要额外处理比如用$(( ))做算术num5 echo $((num * 2))引用变量的时候两种写法$name和${name}。大多数情况下两者等价但强烈建议大家养成用${name}的习惯。原因很简单边界清晰。比如我要拼一个字符串hello_world有变量hello你写$hello_worldShell会去找hello_world这个变量而不是hello加上_world。但${hello}_world就永远不会出错。变量加引号也是个老生常谈的问题。双引号内会做变量展开单引号内是原样输出namezhangsan echo 你好$name echo 你好$name前者输出你好zhangsan后者输出你好$name。日常业务处理中想展开变量就用双引号想原样保留字符串就用单引号。2.2 变量命名与有效性检查变量的名字也有讲究。Shell变量名由字母、数字、下划线组成不能用数字开头。1name是非法变量名_name是合法的。这个细节在面试题里经常出现。定义只读变量用readonlyreadonly CONFIG_FILE/etc/myapp.conf CONFIG_FILE/tmp/other.conf # 报错readonly variable定义环境变量用export。不带export的变量是当前Shell私有的子进程拿不到。这个必须记牢因为很多脚本里变量明明定义了但子进程里取不到原因就是没export。变量有效性检查是很多人忽略的点。脚本里用到用户传进来的参数最好先检查是不是为空。常见做法if [[ -z ${src} ]]; then echo src不能为空 2 exit 1 fi-z判断字符串长度是否为0-n判断长度是否非0。这里${src}要加花括号是为了配合:-这类参数扩展。你要习惯${var:-default}这种写法它的意思是如果var未定义或为空就用default值替代。这个在写容错脚本时特别有用。2.3 位置参数、特殊变量与环境变量脚本运行时传进来的参数用位置参数来拿$0脚本本身的文件名。$1、$2、$3第1、2、3个参数。$#参数总数。$所有参数每个参数是独立的字符串推荐使用。$*所有参数会被看成一个字符串。$?上一条命令的退出码0表示成功非0表示失败。$$当前脚本的进程ID。$!后台执行的上一个任务的进程ID。$和$*的区别经常被拿来当面试题。简单说$更适合遍历参数因为它能保留每个参数的边界$*适合把参数拼成一句话。看个例子for arg in $; do echo 参数: $arg done如果脚本被这样调用./test.sh hello world foo bar用$能完整打印出两句。但换成$*只会打印一句因为所有参数被合并成了一个字符串。还有个特别实用的命令shift。它的作用是左移位置参数$2变成$1$3变成$2以此类推。在处理未知数量的参数时配合while循环非常方便while [[ $# -gt 0 ]]; do echo 当前参数: $1 shift done环境变量这块记住一点环境变量是进程级别的全局数据。子进程会继承父进程的环境变量但子进程里改环境变量父进程感知不到。这也是为什么export的变量在多个脚本协作时特别重要——你要把某个配置传给子脚本就必须用export导出。3. 一份能落地的Shell编程规范3.1 命名、文件头与安全选项先说命名。变量名建议全部小写单词之间用下划线分隔比如backup_dir、log_file。全大写的变量名留给环境变量和只读常量比如PATH、HOME、MAX_RETRIES。函数名建议用动词开头比如backup_files、send_mail这样读脚本的人一眼就知道这个函数干了什么。文件头我强烈建议统一写。每新建一个脚本顶部先放这些内容#!/usr/bin/env bash # # Description: 这个脚本做什么 # Author: 你的名字 # Date: 2024-01-01 set -euo pipefailset -euo pipefail这三件套特别关键。set -e脚本中任何一条命令返回非0退出码整个脚本立刻退出。避免“前面失败了后面还在继续跑”的连环炸。set -u使用未定义变量时直接报错。这个对抓变量拼写错误非常有用。set -o pipefail管道中只要有一个命令失败管道整体的退出码就是失败的。没有它cmd1 | cmd2只要cmd2成功就算cmd1挂了管道也认为成功。但set -e也有坑。比如你在if判断里执行命令命令返回非0时-e不会让你退出因为这是“预期内”的失败。另外命令替换或函数返回值在set -e下可能不会触发退出这个需要自己多测。我见过不少脚本因为盲目开set -e某条命令在该失败的时候没退出导致后续逻辑错乱。所以建议开set -e的同时对不重要的命令主动加上|| true明确告诉Shell“这条允许失败”。脚本执行出错时最好能吐出一个有帮助的报错。我常用的方式是写一个die函数die() { echo [ERROR] $* 2 exit 1 }用法[[ -f $file ]] || die 文件不存在: $file。3.2 引号、判断与循环的规范写法判断语句里我统一推荐用[[ ]]而不是[ ]。[[ ]]是bash的内置关键字支持模式匹配、正则匹配也不会因为变量里带空格而触发分词问题。老掉牙的[ ]对空变量不加引号的场景特别敏感。看这两个对比# 不推荐 if [ $name zhangsan ]; then ... fi # 推荐 if [[ $name zhangsan ]]; then ... fi字符串比较和整数比较是两个体系。字符串用、!、、整数用-eq、-ne、-lt、-gt、-le、-ge。经常有人把用在整数比较上虽然某些场景下能用但一旦变量是字符串整数比较的-eq报错而不会。规范的做法是严格区分count5 if [[ $count -eq 5 ]]; then echo count等于5 fi循环方面for循环最常见for i in {1..10}; do echo 第 $i 次 done遍历文件内容时别用for line in $(cat file)因为文件里万一有空格或通配符就会被拆得乱七八糟。更稳的是while readwhile read -r line; do echo $line done $fileread -r能避免反斜杠转义导致的行内容失真。这个细节在解析配置文件时特别重要。3.3 函数、局部变量与代码组织函数是Shell脚本控制复杂度的利器。虽然Shell函数不支持真正的返回值表达式但只要约定好一样能写出清晰代码。定义函数两种写法都行我更推荐func() { ...; }这种兼容性最好backup_files() { local src$1 local dst$2 cp -a $src $dst }函数内部用local声明局部变量这非常重要。很多人写Shell函数里面的变量全是全局的函数一执行就把外部变量覆盖了排错排到怀疑人生。凡是函数内部用到的临时变量一律local。函数“返回值”有两种常用方式return来返回0-255的小整数退出码适合表示成功失败。用echo输出结果配合$(func)取值适合返回字符串。第二种用法要注意函数里不要混入调试输出否则这些输出也会被当成返回值的一部分。比如get_user() { echo zhangsan } name$(get_user)不要在get_user里随便echo debug信息否则name会把调试信息也带进去。代码组织上我习惯把一个大脚本拆成几类配置区所有变量集中在顶部最好带注释。工具函数区日志、错误处理、公共函数。业务函数区每个业务步骤一个函数。主逻辑区解析参数、调用函数。主逻辑放在最后函数定义放在前面。这在其它语言里叫“先声明后使用”Shell里也一样因为Shell是逐行解析的函数还没定义就调用的话会报command not found。另外如果一个项目里脚本很多可以用source来复用公共函数。写一个common.sh里面放日志和通用函数然后在其它脚本里source $(dirname $(readlink -f ${BASH_SOURCE[0]}))/common.shBASH_SOURCE[0]比$0更靠谱因为$0在脚本被source时可能指向父脚本。用了BASH_SOURCE才能准确拿到当前脚本所在的路径避免source的时候路径不对。4. 常见问题与排查技巧实录4.1 变量相关的典型报错与排查Shell脚本报错信息往往比较隐晦但如果你熟悉常见错误一眼就能定位。我整理了下面这几个出现频率最高的报错信息常见原因解决办法command not found: name变量赋值时等号两侧有空格去掉空格写namevaluebad substitution花括号内语法错误比如${var:-检查参数扩展语法unbound variable开启了set -u但用了未定义变量检查变量名拼写或用${var:-}给默认值integer expression expected字符串和整数比较混淆整数比较用-eq、-lt[: too many arguments变量未加双引号值里又含空格把变量用双引号包起来readonly variable对只读变量重复赋值换一个变量名或不要用readonly这里重点说[: too many arguments因为它特别隐蔽。假设有个文件名my file.txt存在变量file里你写if [ -f $file ]展开后其实是if [ -f my file.txt ]test命令收到三个参数它根本没法判断直接抛错。只要写成if [[ -f $file ]]问题就没了。set -u引发的unbound variable也很常见。我经常在脚本里判断某个可选环境变量是否存在if [[ -n ${MY_ENV_VAR:-} ]]; then echo 存在 fi注意括号里是${MY_ENV_VAR:-}末尾有个空默认值这样即使变量未定义也不会报错。4.2 调试技巧从bash -x到shellcheck有一次我排查一个诡异问题脚本在Jenkins里跑老是失败但在本地手动执行就正常。后来开了bash -x才发现脚本里有个变量名拼错了本地环境恰好没有同名变量所以拿到空值没有报错但Jenkins环境里有一个同名环境变量内容还不是正常的配置路径导致后续命令全部跑偏。这就是调试的重要性。Shell脚本调试我常用的手段有这么几个bash -x全局跟踪。执行bash -x script.shShell会把每一条实际执行的命令打印出来展开变量后的样子一清二楚。哪里写错瞬间现形。局部set -x。不想整脚本都打印就在可疑区域前面加set -x后面加set x只跟踪这一段。关键点加日志。用echo或者自定义的log_info函数把关键变量的值打出来。确认变量在运行过程中变成了什么。用shellcheck做静态检查。这工具几乎是业界标配。装上之后跑一遍shellcheck myscript.sh它会指出未加引号的变量、废弃语法、潜在错误还会给出修改建议。我接手过的老脚本经常一跑就是几十条警告跟着改完稳定性直接提升一个档次。排查问题时还有一个二分思路脚本一大段里哪一行挂了不确定时把可疑区域从中间切开一半注释掉看另一半能不能跑。缩小范围后再细致检查。这个思路在完全不知道从哪里下手时效率很高。4.3 避免常见“隐形坑”的实战习惯有些坑不太会直接报错但会导致脚本结果不对。比如命令替换中的多余空格count 5 echo $(( $count 1 ))变量里带了空格算术运算直接报错。所以凡是拿到外部输入先清理一下用sed或参数扩展去掉多余空格count$(echo $count | tr -d )还有文件路径处理。脚本里拼接路径得小心结尾是不是有斜杠。推荐用dirname、basename来处理文件路径而不是硬拼字符串。full_path/usr/local/bin/test.sh dir$(dirname $full_path) base$(basename $full_path)这样不管用户输入的是/usr/local/bin/test.sh还是/usr/local/bin/test.sh/结果都不会错乱。另外尽量不要把临时文件直接写死在/tmp下不加区分。规范做法是用mktemptmp_file$(mktemp) trap rm -f $tmp_file EXITtrap保证脚本退出时清理临时文件哪怕中途报错退出也不会把垃圾留在系统里。这个细节虽然看起来小但在生产环境堆积久了容易引发磁盘空间问题。5. 面试考点与进阶延伸建议5.1 高频Shell变量与规范面试题如果你在准备运维或后端岗位面试下面这些题目命中率很高。我挑了常考的几道附上简洁答案你可以自测一下。Q1单引号和双引号的区别单引号内的字符全部原样保留不会展开变量双引号内会展开变量但不会执行命令替换。拼字符串时推荐双引号。Q2$与$*有什么区别在带引号的情况下$将每个参数当成独立的词$*将全部参数合并为一个字符串。遍历参数时用$。Q3如何判断一个变量是否为数字用正则匹配[[ $var ~ ^[0-9]$ ]]。Q4下面的命令输出什么varhello echo ${var/world/}输出hello因为world在hello中不存在替换不生效。Q5set -euo pipefail分别什么意思-e遇错退出-u使用未定义变量时报错-o pipefail让管道失败时整体返回失败。Q6如何安全读取文件每一行用while read -r line; do ...; done file别用for循环加命令替换。Q7函数里的局部变量为什么重要避免污染全局命名空间。用local声明的变量在函数结束后自动销毁防止函数内部修改外部同名变量降低排错成本。5.2 从基础规范走向更高阶的Shell工程化变量玩得滚瓜烂熟之后Shell脚本的能力边界还可以继续扩展。我自己走过来的路径大致是三个阶段先是把语法弄明白然后把规范立起来最后开始“工程化”。工程化意味着几个方向参数解析标准化。使用getopt或getopts统一处理短参数、长参数和参数默认值替代手动判断$1/$2。这样脚本用起来就像正规命令行工具。日志体系化。脚本里埋入统一的日志函数带时间戳、日志级别、函数名信息出问题时能直接定位到具体函数和变量值。配置外置。把容易变的路径、连接串、阈值全部放到配置文件中脚本启动时读取避免每次改配置都要改脚本。模板化与复用。把公用的“操作块”抽取成函数库统一source不同项目共用一份。维护成本大幅下降。还有一个值得尝试的方向把Shell和Python打通。Shell擅长快速处理文件和调度系统命令Python擅长复杂数据处理。两者结合用Shell写外层调度用Python处理精细逻辑很多任务能做得又快又稳。回到文章标题说的编程规范与变量其实核心就一句话变量是Shell里最容易出错、也最能体现水平的环节。规范不是束缚而是让你在脚本出问题时能少掉一半头发。哪怕你今天只学会一件事——所有变量都用双引号包起来、命名再也不是a/b/c我觉得这篇文章就没白看。最后分享一个小习惯我每次写完脚本都会强制自己跑一遍shellcheck再开一次bash -x看核心流程。几秒钟的事但能省下后面排错的几个小时。这个动作坚持下来你的Shell水平一定会肉眼可见地涨。