GDB传参只有两种可靠方式：一是用set args预设参数后run，参数持久生效且支持变量展开与转义；二是run后直接跟参数，仅当次有效；--args需置于gdb命令行末尾，启动后仍需run执行。
GDB 传参只有两种可靠方式，其他写法基本会失效或被当成 gdb 自身参数
用 set args 预设参数再 run
这是最稳妥、最常被脚本和自动化流程采用的方式。参数在 run 前就绑定到被调试程序上，后续每次 run（包括重启）都会复用这套参数。
-
set args后面直接跟参数，空格分隔，支持 shell 变量展开（如$HOME），但注意：gdb 不做引号解析，带空格的参数必须用单引号或双引号包裹（例如set args '-f' '/path/to file.txt'） - 如果参数里有
$、*等 shell 特殊字符，且你希望由 gdb 而非当前 shell 展开，得用反斜杠转义，比如set args \*\.c - 执行
show args可确认当前设置的参数是否符合预期 - 清空参数用
set args（不带任何内容）
在 run 命令后直接追加参数
这种写法等价于“临时覆盖”，只对当次 run 生效，不影响 set args 的设定值，适合快速测试不同入参。
- 语法就是
run arg1 arg2 --flag value，和终端直接运行程序的格式完全一致 - 注意：不能在
run后换行再输参数；所有参数必须在同一行、run之后紧跟着 - 如果之前用
set args设过参数，这次run会忽略它——run后的参数具有更高优先级 - 常见误操作：
run -d $HOME中的$HOME会被当前 shell 展开，不是 gdb 展开；若想让 gdb 解析变量，得写成run -d \$HOME
用 --args 启动 gdb 时传递参数
这个选项必须放在 gdb 命令行的**末尾**，且只能出现一次，否则 gdb 会报错 Unrecognized option: --args 或把后续内容误认为是 gdb 的子命令。
- 正确写法：
gdb --args ./myapp -v --config config.json；此时-v和--config config.json是myapp的参数，不是 gdb 的 - 错误写法：
gdb --args -q ./myapp -v——-q会被当作 gdb 参数，而--args后面没跟可执行文件，gdb 直接报错退出 - 启动后仍需手动输入
run才真正执行；也可以接着用set args覆盖掉命令行里传的参数
最容易被忽略的一点：无论哪种方式，gdb 本身不处理引号嵌套或 shell 重定向（如 >、|）。像 ./app 这类重定向必须由 shell 完成，不能塞进 <code>set args 或 run 后面——它们只负责构造 argv[] 数组，不接管 stdin/stdout 重连。
