Bash 参数转发："$@" 保留的边界，为什么 "$*" 会合成一个参数
包装脚本最容易丢掉的是参数边界
给常用命令包一层脚本时，常见需求是先做一点准备，再把用户提供的参数交给真正的程序。参数里一旦出现空格、空字符串或星号，肉眼看上去一样的一串文本，传过去却可能已经变成不同数量的参数。问题发生在命令启动之前，后面的程序无法知道原来的分界在哪里。
在命令参数的位置，双引号包住的 "$@" 会把每个位置参数分别展开为一个参数；"$*" 则把它们连接成一个字符串。两者都写了引号，但引号保护的是不同展开结果，不能只用“有没有双引号”判断包装脚本是否正确。
让接收函数逐项展示收到的内容
将下面代码保存为脚本，用 Bash 执行，本文在五点二验证。它只定义函数、设置当前脚本的位置参数并打印结果，不调用外部业务命令。接收函数先打印数量，再逐项加上方括号，空字符串因此也能清楚看见。
输入刻意包含带空格的名称、空参数和字面星号。示例还在子 shell 中更改连接分隔符，避免影响外层环境。最后清空参数列表，分别检查“没有任何参数”和“只有一个空参数”，这两种状态对命令行接口往往具有不同含义。
AI概念配图，非真实界面
show() {
printf 'count=%s\n' "$#"
local item
for item in "$@"; do
printf '[%s]\n' "$item"
done
}
set -- 'alpha beta' '' '*.txt'
printf '%s\n' 'at:'
show "$@"
printf '%s\n' 'star:'
show "$*"
(
IFS=':,'
printf '%s\n' 'star with custom IFS:'
show "$*"
)
set --
printf '%s\n' 'empty at:'
show "$@"
printf '%s\n' 'empty star:'
show "$*"
printf '%s\n' 'all argument checks passed'合并后，空参数的身份就难恢复了
第一组输出数量为三，第二项是空方括号；第二组数量变成一，所有内容位于同一对方括号里。星号始终保持字面值，因为这里的展开处于双引号之中。由此可以直接确认，"$*" 的问题不是把星号变成了文件列表，而是主动合并了参数。
连接分隔符取 IFS 的第一个字符，示例把它设为冒号和逗号，结果只用冒号连接，空参数表现为连续两个冒号。这种结果适合明确需要拼接文本的场景，却不是任意参数数组的可逆编码，因为原来的参数本身也可能含有同样的分隔符。
如果 IFS 未设置，连接使用空格；如果设置为空字符串，连接时没有分隔符。排查包装脚本时要同时检查展开形式和当前分隔规则。不要通过在别处偶然设置 IFS 来“修复”参数传递，那样会让函数行为依赖难以察觉的环境状态。
零参数与一个空参数也要分别验收
清空列表后，"$@" 在这个调用位置不产生任何参数，接收函数打印零；"$*" 仍作为一个空字符串参数传入，数量为一。对于接收路径、筛选条件或文本内容的工具，空字符串可能表示当前目录、清空字段或者无效输入，不能把它与未提供混为一谈。
转发时通常让 "$@" 独立占据一个命令参数位置。若把前缀或后缀直接粘在同一对引号中，文字会与首尾参数连接，语义随之变化。需要给每个参数添加前缀时，应逐项构建数组，再用带引号的数组展开交给目标程序。
不要先把参数存进普通字符串，再用 eval 执行来恢复它们。字符串会失去原始边界，而重新解析还会赋予特殊字符额外含义。Bash 数组或位置参数可以直接保存结构，既便于检查数量，也能让每一项的内容保持原样。
这套规则解决的是 shell 层的分界，目标程序如何解释选项仍由它自己决定。若某个值以短横线开头，需要结合目标命令对选项终止符的支持来处理。验证包装脚本时，至少保留普通文本、空格、空值、字面星号和零参数五类样本。
