Bash命令手动执行正常 脚本内多词参数解析失败问题排查

核心是Bash的变量展开规则与引号作用的认知偏差：

• 把动态生成的参数存在普通字符串变量$generated_flags里时，字符串中写的--arg2="val2 val3"里的双引号，只是普通的文本字符，不是Bash用来标记参数边界的语法符号。Bash只会在初始解析脚本代码的阶段识别引号的语法作用，进入变量展开环节时，Bash已经完成了语法解析，不会再把变量内容里的引号当成语法处理。
• 直接写$generated_flags传参时，Bash会按照默认的IFS规则（按空格、制表符、换行）对变量内容做单词拆分，完全忽略内容里的引号，最终把这段内容拆成四个独立片段：subcommand、--arg1=val1、--arg2="val2、val3"。最后那个带尾引号的val3"就被Click当成独立传入的命令，触发找不到命令的报错。
• 把echo打印的命令复制到终端手动执行能跑通，是因为手动输入时双引号是直接传给Bash解析器的语法符号，Bash会在解析阶段识别引号，把val2 val3合并成一个参数，和变量展开时的处理逻辑完全不同。

不要用普通字符串存储多参数，用Bash原生数组存储独立参数，这是Bash处理动态参数列表的标准、安全方案，完全不需要eval，也不需要自定义分隔符：

1. 替换参数存储逻辑：不要把所有参数拼成长字符串，生成参数时直接按顺序把每个独立参数存入数组，多词参数不需要额外嵌套引号，直接作为单个数组元素写入即可，示例：

   # 错误写法：普通字符串存参数，会被空格意外拆分
   # generated_flags="subcommand --arg1=val1 --arg2=\"val2 val3\""
   
   # 正确写法：数组存参数，每个元素对应一个独立参数
   generated_flags=(
     subcommand
     --arg1=val1
     --arg2="val2 val3" # 此处引号是代码层面标记字符串边界用的，不会作为参数内容传入
   )
   

2. 修正函数调用写法：传递数组参数时，使用"${数组名[@]}"的带双引号展开写法，保证每个数组元素被作为完整的独立参数传递，不会被空格拆分：

   print_and_run time docker run our-container:latest "${generated_flags[@]}"
   

3. 修正print_and_run函数内部的参数展开逻辑，所有数组切片、参数传递的位置都要给展开表达式加双引号，避免隐式单词拆分：

   print_and_run() {
     local command=("$@")
     if [[ ${command[0]} == "time" ]]; then
       # 打印命令时用*展开拼接成可读字符串即可
       echo "Your command: time ${command[*]:1}"
       # 执行时必须用带双引号的@展开，保证参数边界正确
       time "${command[@]:1}"
     fi
   }
   

补充说明：团队反对eval是合理的，eval会把传入的字符串整体作为Bash代码重新解析，只要参数内容包含恶意构造的特殊字符（比如; rm -rf /、$(恶意命令)）就会触发命令注入，安全风险极高。自定义分隔符的方案本质是重新实现一套参数边界标记逻辑，既容易出现分隔符和业务参数冲突的问题，也远不如Bash原生数组的边界标记可靠。

内容的提问来源于stack exchange，提问作者Raven