写Shell脚本的人大概都有过这样的经历：翻出一段几个月前写的脚本，看到里面密密麻麻的$?、$@、$#，脑子先卡壳三秒，然后默默去搜索引擎里再查一遍。这些位置参数和特殊变量，说难不难，说简单也真容易记混——尤其是$*和$@这一对，长得像、用起来更像，但只要引号一加，行为立刻分道扬镳。我见过不少脚本在参数里带空格的场景下直接崩掉，追根溯源就是这里没搞明白。

这篇内容就是把这些Shell特殊变量一次性捋清楚：它们各自代表什么、在什么场景下用、引号加与不加有什么区别、踩过哪些坑、怎么在真实脚本里组合使用。不管你是刚接触Shell的新手，还是写了几年脚本但一直靠"试出来"的老手，都能从这里找到可以直接抄作业的结论和排查思路。全文围绕$#、$*、$@、$?、$0到$n这一组变量展开，配合大量可复现的示例，把每个符号的边界条件都掰开揉碎讲明白。

1. 位置参数家族的全景地图：从$0到$n到底谁是谁

在动手写任何一行示例之前，先把这组变量的"身份关系"理清楚。Shell脚本在运行时，会把命令行上敲入的内容按空格切分成若干段，每一段就是一个位置参数。脚本内部通过$加数字的方式去引用它们，这套机制就是位置参数体系。理解这套体系的关键在于：分清哪些是"脚本自己的名字"，哪些是"传进来的数据"，哪些是"Shell自动维护的状态"。

1.1 $0不是参数，是脚本的"身份证"

很多人第一次写脚本时会误以为$0是第一个传入的参数，结果打印出来发现是脚本自己的路径。$0代表的是当前脚本的名称或调用路径，具体内容取决于你是怎么调用它的。用相对路径调用就显示相对路径，用绝对路径调用就显示绝对路径，通过软链接调用则显示软链接的名字。

#!/bin/bash echo "脚本名: $0" echo "第一个参数: $1"

假设保存为demo.sh，执行./demo.sh hello，输出是：

脚本名: ./demo.sh 第一个参数: hello

这个特性在实际脚本里非常有用。比如写一个用法提示函数，需要告诉用户"你应该怎么调用我"，这时候$0就是天然的素材：

usage() { echo "用法: $0 <源目录> <目标目录>" exit 1 }

注意：$0在通过source或.加载脚本时，行为会变得微妙——它可能显示的是调用方的Shell名称而不是被加载的脚本名。如果你的脚本既要能被直接执行、又要能被source，涉及$0的逻辑需要额外判断。

1.2 $1到$9与${10}以上的写法差异

$1到$9可以直接写，但到了第十个参数，$10会被Shell解释成$1后面跟一个字符0，而不是第十个参数。这是Shell解析的一个经典陷阱。正确写法是${10}、${11}，用花括号把变量名边界明确圈出来。

#!/bin/bash echo "第1个: $1" echo "第10个: ${10}" echo "第11个: ${11}"

执行./demo.sh a b c d e f g h i j k，输出中${10}是j，${11}是k。如果写成$10，输出会变成a0——因为$1是a，后面紧跟的0被当作普通字符拼接上去了。

这个坑在参数数量不固定的脚本里特别容易踩。我的习惯是：只要参数可能超过9个，一律用花括号写法，哪怕当前只用到前几个，统一风格能避免以后扩展时忘记改。

1.3 $#：参数个数的计数器

$#返回的是位置参数的总个数，注意它不包含$0。传了三个参数，$#就是3；一个没传，$#就是0。这个变量最常见的用途是做参数数量校验：

if [ $# -lt 2 ]; then echo "至少需要两个参数" exit 1 fi

这里有个细节值得说：$#在判断时最好加上引号写成"$#"，虽然数字本身不会有空格问题，但养成习惯没坏处。更重要的是，$#的值在脚本执行过程中是只读的，你不能给它赋值，它始终反映最初传入的参数个数。有些脚本会在处理过程中用shift消耗参数，$#会随之减少——这一点在循环处理参数时非常关键，后面会专门讲。

1.4 一张表看清所有位置参数变量

把上面这些变量集中对照，记忆负担会小很多：

这张表建议直接记在脑子里，写脚本时随时对照。下面几节会把$*、$@、$?这几个容易混淆的单独拎出来深挖。

2. $*与$@：长得像双胞胎，引号一加就分家

$*和$@是Shell里最容易被混为一谈的一对变量，因为它们在不加引号时表现几乎一样，但只要加上双引号，行为立刻产生本质区别。这个区别在处理"参数里带空格"的场景下会直接决定脚本能不能正常工作。我见过太多脚本因为这里没搞清楚，遇到文件名带空格的输入就彻底崩盘。

2.1 不加引号时：两者都是"按空格重新切分"

先看一个最朴素的对比实验：

#!/bin/bash echo "--- 不加引号 ---" for arg in $*; do echo "[$arg]" done echo "--- 不加引号 @ ---" for arg in $@; do echo "[$arg]" done

执行./demo.sh "hello world" foo bar，两段输出完全一样：

[hello] [world] [foo] [bar]

注意"hello world"这个本来是一个整体的参数，被拆成了hello和world两个。原因是不加引号时，Shell会对变量展开的结果再做一次单词切分（word splitting），空格成了分隔符。$*和$@在这个阶段没有区别，都被打散重组了。

这就是为什么很多脚本"平时能用，一遇到带空格的文件名就出错"——问题往往就出在这里。

2.2 加双引号后：$*是一个整体，$@是多个独立个体

加上双引号，两者的命运彻底分岔：

#!/bin/bash echo "--- \"\$*\" ---" for arg in "$*"; do echo "[$arg]" done echo "--- \"\$@\" ---" for arg in "$@"; do echo "[$arg]" done

同样执行./demo.sh "hello world" foo bar，输出变成：

--- "$*" --- [hello world foo bar] --- "$@" --- [hello world] [foo] [bar]

"$*"把所有参数用空格（实际上是IFS的第一个字符）拼接成一个字符串，循环只跑一次；"$@"则保留每个参数的独立性，循环跑三次，hello world完整地作为一个元素。

这个区别的本质在于："$*"展开后是"一个字符串"，"$@"展开后是"一组字符串"。前者适合需要把参数整体传给另一个命令的场景，后者适合需要逐个处理参数的场景。

2.3 用IFS改变$*的拼接分隔符

"$*"拼接时用的分隔符来自环境变量IFS（Internal Field Separator）的第一个字符，默认是空格。这意味着你可以临时改IFS来改变拼接结果：

#!/bin/bash OLD_IFS=$IFS IFS="," joined="$*" IFS=$OLD_IFS echo "$joined"

执行./demo.sh a b c，输出是a,b,c。这个技巧在需要把参数拼成逗号分隔列表传给下游程序时很好用。但要注意：改完IFS一定要改回来，否则后续所有依赖默认IFS的代码都会出问题。我一般用子shell或者保存旧值再恢复的方式，避免污染全局环境。

提示：IFS的影响范围比想象中大，它会影响for循环的切分、read命令的分隔、甚至某些命令的参数解析。临时修改后忘记恢复，是排查起来很痛苦的一类bug。

2.4 实战选型：什么时候用哪个

把上面的结论落到实际场景，选型逻辑其实很清晰：

• 需要把全部参数原样传给另一个命令，用"$@"。比如写一个包装脚本，把收到的参数透传给真正的执行程序：

#!/bin/bash exec /usr/local/bin/real_tool "$@"

这里必须用"$@"，如果用"$*"，带空格的参数会被合并成一个，下游程序收到的参数个数就错了。

• 需要把参数拼成一个可读的字符串（比如打日志、生成提示信息），用"$*"：

echo "收到的参数: $*"

• 需要逐个遍历处理每个参数，用"$@"配合for循环：

for file in "$@"; do process "$file" done

记住一条铁律：只要涉及参数传递和遍历，默认用"$@"，几乎不会错。"$*"只在明确需要"合并成一个字符串"时才用。这条经验帮我避开了无数个带空格文件名的坑。

3. $?：退出状态码，脚本错误处理的中枢神经

$?保存的是上一条命令执行完毕后的退出状态码，是一个0到255之间的整数。0表示成功，非0表示失败（不同数值代表不同的失败原因）。这个变量是Shell脚本做错误处理的核心，但它的一个特性让很多人栽跟头：它只反映"紧邻的上一条命令"的状态，任何一条命令执行后它都会被覆盖。

3.1 退出码的语义约定与常见取值

虽然理论上0到255都可以自定义，但业界有一套约定俗成的语义：

写脚本时，自己的脚本返回什么码也应该遵循这套约定。比如参数校验失败返回2，比返回1更能让调用方区分"是用法错了"还是"是执行出错了"。

3.2 最经典的坑：$?被中间命令覆盖

看这段代码：

#!/bin/bash grep "pattern" somefile.txt echo "grep的结果是: $?"

看起来没问题，但如果中间插了一条命令：

#!/bin/bash grep "pattern" somefile.txt echo "检查一下" # 这条echo执行成功，$?变成0 echo "grep的结果是: $?" # 这里拿到的是echo的退出码，不是grep的

第二条echo执行成功后，$?被重置为0，原本grep的失败状态就丢了。这是$?最典型的误用。正确做法是命令执行完立刻保存状态：

#!/bin/bash grep "pattern" somefile.txt status=$? echo "检查一下" echo "grep的结果是: $status"

把$?赋值给一个普通变量，后续随便怎么操作都不会影响这个保存下来的值。这个习惯我强烈建议养成——只要退出码后面还要用，第一件事就是存起来。

3.3 与if、&&、||的组合用法

$?最常见的搭档是if语句，但更地道的写法是直接用命令本身作为条件：

if grep -q "pattern" somefile.txt; then echo "找到了" else echo "没找到" fi

这里不需要显式写$?，if会自动判断上一条命令的退出码。同理，&&和||也是基于退出码工作的：

mkdir -p /tmp/work && cd /tmp/work || { echo "切换目录失败"; exit 1; }

&&表示前面成功才执行后面，||表示前面失败才执行后面。这种链式写法比一堆if嵌套清爽得多，但要注意链式命令中$?只反映整条链的最终结果，中间某一步的状态是拿不到的。如果需要精确知道哪一步失败，还是得拆开写并逐个保存状态。

3.4 set -e与$?的微妙关系

很多脚本开头会写set -e，让脚本在任意命令失败时立即退出。这确实能减少手动检查$?的负担，但它和$?的配合有几个反直觉的地方：

• 在if条件、&&、||、!后面的命令失败不会触发set -e退出，因为这些位置本来就是"允许失败"的语境。
• 管道命令默认只看最后一个命令的退出码，前面命令失败不会触发退出，除非开启set -o pipefail。
• 某些命令在特定参数下返回非0但并非真错误（比如grep没匹配到返回1），在set -e下会导致脚本意外中止。

我的经验是：set -e适合简单脚本，复杂脚本里它反而会制造隐蔽问题。如果用了set -e，就要对每个可能"合法失败"的命令格外小心，必要时用|| true兜底，或者干脆不用set -e、老老实实检查$?。

4. 参数处理实战：shift、遍历与健壮性设计

把前面这些变量真正用起来，绕不开参数处理的实际场景。这一节讲几个高频套路：怎么遍历所有参数、怎么用shift逐个消费、怎么写出对空格和特殊字符都健壮的脚本。

4.1 用shift逐个消费参数

shift命令的作用是把位置参数整体左移一位：原来的$2变成$1，$3变成$2，以此类推，同时$#减一。配合while循环，可以实现"逐个处理参数"的效果：

#!/bin/bash while [ $# -gt 0 ]; do echo "处理参数: $1" shift done

这种写法在处理"选项+值"形式的参数时特别顺手：

#!/bin/bash while [ $# -gt 0 ]; do case "$1" in -f|--file) filename="$2" shift 2 ;; -v|--verbose) verbose=1 shift ;; *) echo "未知参数: $1" exit 2 ;; esac done

注意-f这种带值的选项要shift 2（消费掉选项和它的值），而-v这种开关型选项只需shift一次。shift后面跟的数字超过剩余参数个数时会报错，所以循环条件[ $# -gt 0 ]是必要的保护。

4.2 遍历参数时引号的正确姿势

回到$@的遍历，正确的写法永远是：

for arg in "$@"; do echo "参数: $arg" done

这里"$@"的双引号不能省，$arg的双引号也不能省。前者保证带空格的参数不被拆开，后者保证echo时参数内容完整。我见过有人写成for arg in $@（不加引号），在参数带空格时直接出错；也见过echo $arg（不加引号），导致参数里的连续空格被压缩、通配符被意外展开。

注意：echo $arg在arg包含*时会展开成当前目录的文件列表，这是通配符展开（globbing）在作怪。加引号写成echo "$arg"就能避免。这个坑在参数可能包含用户输入时尤其危险。

4.3 参数校验的完整模板

一个健壮的脚本，开头应该有完整的参数校验。下面这个模板可以直接抄：

#!/bin/bash set -u # 引用未定义变量时报错 if [ $# -lt 2 ]; then echo "用法: $0 <源文件> <目标文件>" >&2 exit 2 fi src="$1" dst="$2" if [ ! -f "$src" ]; then echo "错误: 源文件不存在: $src" >&2 exit 1 fi echo "准备从 $src 复制到 $dst"

几个细节值得说：set -u让引用未定义变量时直接报错，避免$1没传时静默变成空字符串；错误信息输出到>&2（标准错误）而不是标准输出，方便调用方区分正常输出和错误；退出码用2表示用法错误、1表示执行错误，符合前面的语义约定。

4.4 处理"参数数量不定"的场景

有些脚本的参数个数不固定，比如批量处理文件。这时候$#和"$@"的组合就派上用场：

#!/bin/bash if [ $# -eq 0 ]; then echo "请至少提供一个文件" >&2 exit 2 fi echo "共收到 $# 个文件" for f in "$@"; do if [ -f "$f" ]; then echo "处理: $f" else echo "跳过（不是文件）: $f" >&2 fi done

这里$#用来判断有没有传参数，"$@"用来安全遍历。如果参数里混入了带空格的文件名，这套写法能完整保留每个文件名，不会出错。

5. 那些年踩过的坑与排查思路

光知道定义不够，真正让人头疼的是实际使用中那些"看起来对、跑起来错"的场景。这一节把我遇到过和见过的典型问题整理出来，每个都附上排查链路，方便你遇到类似情况时对照定位。

5.1 参数带空格导致脚本行为异常

现象：脚本在测试环境跑得好好的，一到生产环境处理真实文件名就出错，报"文件不存在"。

排查链路：先确认出错的文件名是否带空格或特殊字符；再检查脚本里所有引用参数的地方是否加了双引号；重点看for循环、命令参数传递、变量赋值这三处。

根因：不加引号的变量展开会触发单词切分，带空格的文件名被拆成多个"参数"，后续命令自然找不到文件。

修复：所有变量引用统一加双引号，遍历用"$@"，传参用"$@"。改完后用带空格的文件名做回归测试。

5.2 $?判断失效的隐蔽原因

现象：明明命令失败了，if [ $? -ne 0 ]却判断为成功。

排查链路：检查$?和失败命令之间是否插入了其他命令（包括echo、赋值、甚至空行里的注释不影响但命令会影响）；检查是否在管道中只看了最后一个命令的状态；检查是否在if条件里又执行了别的命令。

根因：$?只反映紧邻的上一条命令，中间任何命令都会覆盖它。

修复：命令执行后立刻status=$?保存，后续用$status判断；管道场景开启set -o pipefail。

5.3 $10被解析成$1加0

现象：脚本传了十个以上参数，第十个参数取出来不对，变成了第一个参数加个0。

排查链路：检查代码里是否写了$10这种形式；确认Shell版本（大多数Shell都有这个行为）。

根因：Shell解析$10时按"$1后跟字符0"处理，而不是"第十个参数"。

修复：改用${10}。同时把脚本里所有两位数以上的位置参数引用统一改成花括号形式。

5.4 source加载时$0和$#的意外值

现象：脚本直接执行正常，被source加载后$0变成了Shell名，$#变成了调用方的参数个数。

排查链路：确认脚本是被执行还是被source；检查脚本里是否依赖$0做路径推导；检查$#相关逻辑是否假设了"参数来自本脚本"。

根因：source是在当前Shell环境里执行脚本内容，位置参数和$0继承的是调用方的上下文，不是脚本自己的。

修复：如果脚本需要同时支持两种加载方式，用${BASH_SOURCE[0]}获取脚本自身路径（这是bash特性），并在脚本开头判断是否被source，必要时保存和恢复位置参数。

5.5 通配符被意外展开

现象：参数里传了*或?，脚本里echo $arg输出了一堆文件名。

排查链路：检查变量引用是否加了引号；确认参数内容是否包含通配符字符。

根因：不加引号的变量展开会触发通配符展开（globbing），*被替换成当前目录的文件列表。

修复：变量引用一律加双引号。如果确实需要通配符展开，用set -f临时关闭globbing，或者显式用eval控制展开时机。

6. 把这些变量用成肌肉记忆

写到这里，这些变量的用法基本覆盖全了。最后分享几个我长期实践下来觉得最值得固化的习惯，都是些小动作，但能省掉大量排查时间。

第一个习惯：写脚本先写参数校验。开头就把$#检查、$0用法提示、必要参数的-f/-d判断写全，后面逻辑再复杂也不慌。这个模板我几乎每个脚本都套，改改参数名就能用。

第二个习惯：变量引用默认加双引号。"$var"、"$@"、"$1"，养成条件反射。不加引号的场景反而是少数，需要通配符展开或明确要单词切分时才考虑。这个习惯能挡掉八成以上的"带空格就出错"问题。

第三个习惯：$?用完立刻存。只要退出码后面还要用，第一行就status=$?。别指望它能在中间命令执行后还保持原值，它不会。

第四个习惯：两位数以上参数一律花括号。${10}、${11}，哪怕现在只用到$1到$3，统一风格以后扩展不踩坑。

第五个习惯：调试时用set -x看展开结果。脚本行为诡异时，在开头加一行set -x，Shell会把每条命令展开后的实际内容打印出来，$*和$@的区别、引号有没有生效、通配符有没有展开，一目了然。排查完记得删掉或改成set +x。

这些变量本身不复杂，难的是在写脚本的每一行都保持对它们的敏感度。多写几个带空格文件名、多参数、错误处理的真实脚本，这些符号自然就从"要查文档"变成"手比脑子快"了。