gdb --args 是最稳妥的传参方式，将参数与可执行文件绑定，避免 run 时遗漏或覆盖；需用 show args 验证，含空格或特殊字符时须加双引号，后续可用 set args 覆盖。
gdb --args 启动时直接传参最稳妥
直接在命令行用 gdb --args 启动，是传递参数最不容易出错的方式。它把参数和可执行文件绑定在一起，后续 run 时不会漏掉、也不会被意外覆盖。
常见错误现象：只写 gdb ./a.out 进入后忘了 set args，一敲 run 就报错或行为异常，因为程序实际收到的是空参数列表。
gdb --args ./myapp --config config.json -v --port 8080- 进入后直接
run，参数自动生效 - 如果之后想改参，仍可用
set args ...覆盖，但首次推荐用--args
set args 在 gdb 内设置参数要配合 show args 验证
set args 看似简单，但容易被忽略两个关键点：它只影响下一次 run，且不保存历史；一旦中间执行过一次 run，再输新参数必须重新 set args。
使用场景：调试过程中反复修改参数组合（比如测试不同端口号、不同输入文件），又不想反复退出重进 gdb。
- 输入
set args -i input.txt -o output.bin - 务必紧接着执行
show args—— 它会原样回显你刚设的值，确认没因空格、引号或转义丢内容 - 如果参数含空格或特殊字符（如
"my file.txt"），set args中必须加引号，否则会被 shell 拆开
run 命令后面跟参数是临时覆盖，但仅限本次
run 后直接加参数（如 run --debug --log-level=3）会忽略之前 set args 的设置，只对这一次生效。这个特性适合快速验证某个参数分支，但不适合稳定复现。
容易踩的坑：误以为 run -x 设了新参数后，下次 run（不带参数）还会沿用，其实不会——下次 run 会回到上一次 set args 的值，或者为空。
- 上次
set args --mode=prod，然后run --mode=dev→ 当前运行 dev 模式 - 再敲一次
run（无参数）→ 实际运行的是--mode=prod，不是 dev - 若想让 dev 成为默认，必须
set args --mode=dev，再show args确认
参数里有空格、引号或 shell 特殊字符怎么办
GDB 对参数的解析发生在 shell 层和 gdb 内部两层，引号处理稍有不慎就会导致程序收到的 argv 元素数量或内容错误。
真实案例：调试一个读取路径的 C++ 程序，传 /tmp/my data/，结果程序报“找不到目录”，其实是 gdb 把 my data/ 拆成了两个 argv 元素。
- 正确做法：在
set args或--args中，对含空格的参数整体加双引号，如set args "/tmp/my data/" --flag - 避免单引号嵌套：GDB 不支持单引号包裹后再用双引号，统一用双引号即可
- 反斜杠转义也可行，但可读性差，比如
set args /tmp/my\ data/，容易漏掉空格前的 \
真正麻烦的不是怎么传参，而是传完之后程序收不到预期的 argv —— 所以每次设完，最好在断点处用 info args 或 p argc、p argv 看一眼，确认参数数量和内容和你敲的一致。
