Bash 中 curl 请求突然进入后台，URL 后半段参数丢失

执行一条 curl 命令后，终端先显示类似 [1] 12345 的作业编号和进程号，提示符立即回来，响应或错误却过一会儿才冒出来。接口还可能只收到第一个查询参数，脚本读取的退出状态也与 curl 最后报的错误不一致。

如果命令中的 URL 直接包含未加引号的 &，先检查 shell 是否已经把它当成后台执行符。下面的错误示例只用于说明 Bash 的解析方式，不要直接用它请求真实业务接口：

curl https://api.example.com/items?type=book&limit=10

本文针对在 Bash 命令行或 Bash 脚本中直接书写 URL 的情况。其他 shell 的报错和作业提示可能不同；通过程序参数数组直接调用 curl，也不经过同一套 shell 解析。域名、路径、查询参数及进程号都是示例。

& 把一条请求拆成了两段

在 Bash 中，未引用的 & 结束前面的命令，并让它异步执行。上面的文本因此相当于先把下面这条命令放到后台：

curl https://api.example.com/items?type=book

然后 shell 再解释 limit=10。这个例子中的后半段恰好是合法的变量赋值，不一定会报 command not found，所以参数丢失可能比报错更隐蔽。如果后半段不是合法赋值，还可能被当成另一条命令。

退出状态也受这次拆分影响。Bash 不等待后台命令完成；启动异步命令这一动作的返回状态为 0。随后执行的赋值或其他命令又会改变 $?。直接在提示符返回后检查 $?，不能据此认定后台 curl 已成功。

curl 自己的 DNS、连接或 HTTP 错误要另行判断。例如，截短后的请求仍可能报无法解析主机；给 URL 加引号可以恢复参数完整性，却不会修复一个本来就无法解析的主机名。

检查原命令时应保留标点结构。把真实 URL 简化成没有查询参数的地址，会把触发问题的 & 一起删掉；对外提供脱敏命令时，可以替换参数值，但保留分隔符和引号位置。

固定 URL 用引号包住完整地址

对于直接写在命令中的固定地址，使用一对英文单引号：

curl 'https://api.example.com/items?type=book&limit=10'

单引号让 Bash 把其中的字符按字面值传递，整个地址成为 curl 的一个参数。不要只给 & 后半段加引号，也不要使用中文排版引号代替 shell 引号。

保留原请求已有的方法、认证头和请求体，只修改 URL 的引用方式。示例是普通 GET，不能把它当成原有 POST 命令的完整替代品。

如果 URL 已经保存在变量里，引用变量时用双引号：

request_url='https://api.example.com/items?type=book&limit=10'
curl "$request_url"

这里的单引号保存固定文本，双引号允许展开变量，同时把结果保留为一个参数。写成 curl '$request_url' 会把变量名按字面传过去。变量赋值那一行本身也要正确引用，不能在赋值时就让 & 拆开命令。

未引用的变量展开还有分词与文件名展开风险，但变量值中展开出来的 & 不会自动被重新当成 shell 控制运算符。不要把“命令里直接写了未引用的 &”和“变量展开没加引号”说成完全相同的解析过程，也不要为了执行变量中的地址再套 eval。

curl 的 --globoff 只关闭它自己的 URL 范围展开，无法修复 Bash 已经发生的命令拆分。这里仍需修正 shell 引号。

参数值中的 & 与参数分隔符不同

完整地址里的 &limit=10 是两个查询参数之间的分隔符，应保留并放在引号内。把所有 & 一律换成 %26，可能把第二个参数变成第一个参数值的一部分。

如果参数值本来就包含 &，例如希望查询文字 rock & roll，可以让 curl 编码各个值，再组成 GET 查询：

curl --get 'https://api.example.com/items' \
  --data-urlencode 'q=rock & roll' \
  --data-urlencode 'limit=10'

在 name=content 这种语法下，--data-urlencode 编码等号右侧的内容，参数名需已经是可用的编码形式。这里传入原始值，避免先写成百分号编码再重复编码。--get 把这些数据放到 URL 查询部分；只加 --data-urlencode 而漏掉 --get，会按其默认用途发送 POST 数据。

这是一种组织 GET 参数的写法，不应拿来随意改变原有 POST 请求或重新拼装带签名的 URL。已有签名地址先保留原样，只修正 shell 引号。

在前台检查退出状态和实际参数

选择允许调试、不会写入业务数据的接口，修正引号后在前台执行。下面的 Bash 写法把 curl 的状态立即保存下来，失败分支也适用于启用了 set -e 的脚本：

request_status=0
curl 'https://api.example.com/items?type=book&limit=10' || request_status=$?
printf 'curl exit status: %s\n' "$request_status"

命令里没有用于后台执行的尾随 &，Bash 会等待 curl 结束，再执行状态输出。不要在 curl 与状态捕获之间插入其他命令。普通 curl 默认不会仅因 HTTP 404 或 500 就返回失败，因此状态为 0 也不等于接口业务成功，仍需检查响应状态与内容。

需要核对实际发送的地址时，可以在同一个安全接口上临时启用详细输出：

curl --verbose 'https://api.example.com/items?type=book&limit=10'

确认请求目标同时包含两个参数，终端不再因 URL 中间的 & 启动后台作业，接口收到的参数也符合预期。详细日志可能包含令牌、Cookie、认证头或敏感查询内容，对外分享前必须脱敏，验证后移除调试选项。

如果之前已经误发了请求，加引号不会撤销它。先确认服务端实际收到的请求和产生的结果，再决定是否重试；创建、支付、删除等操作尤其不能靠重复运行来验证。需要撤回脚本修改时，恢复保存的脚本版本并保留正确的 URL 引用方式，不要恢复那条会截断请求的命令。