VSCode中launch.json的attach配置需设request为"attach"，指定processId（或用pid字段）、miDebuggerPath指向真实gdb路径，并确保program路径与运行进程二进制完全一致。
vscode中launch.json的attach配置怎么写
VSCode 调试器本身不直接“连接进程”，而是靠 gdb（或 lldb）通过 attach 命令接管目标进程。关键在 launch.json 里选对 request 类型和必要字段。
-
request必须设为"attach"，不是"launch" -
processId是必须项，但不能写死——你得先查到目标 PID，再填进去；更稳妥的做法是用pid字段配合preLaunchTask或手动输入 -
miDebuggerPath要指向真实可用的gdb（比如/usr/bin/gdb），别用系统默认找不到的别名 -
program字段仍需填写，且路径必须和正在运行的二进制**完全一致**（包括符号表、调试信息、绝对路径），否则断点不生效、变量无法展开
为什么attach后断点不命中
最常见原因不是配置错，而是目标进程没带调试信息、或被 strip 过，或者 VSCode 加载的是另一个同名但不同 build 的可执行文件。
- 确认进程启动时用的是带
-g编译的版本：readelf -S ./myapp | grep debug应有多个.debug_*段 - 检查
launch.json中的program路径是否和/proc/指向同一文件（用/exe ls -l /proc/查看）/exe - 如果进程是 root 启动的，而 VSCode 是普通用户，
gdb默认无权 attach——要么用sudo code --user-data-dir="/tmp/vscode-root"启动 VSCode，要么改内核参数：echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
gdb attach 时提示ptrace: Operation not permitted
这是 Linux 内核的 ptrace 保护机制触发的，和 VSCode 关系不大，本质是当前用户没权限 attach 到那个进程。
- 非 root 进程只能 attach 同组、同用户的进程；跨用户（含 root）默认禁止
- 临时放开：运行
sudo sysctl -w kernel.yama.ptrace_scope=0（重启失效） - 永久放开：把
kernel.yama.ptrace_scope = 0加到/etc/sysctl.conf，然后sudo sysctl -p - 不建议长期关闭；生产环境应改用
sudo -u targetuser gdb --pid=手动调试，再把gdb输出重定向给 VSCode（较复杂，一般只用于排查）
如何避免每次都要手动查 PID
可以自动化获取 PID，但要注意时机：进程必须已启动、且名字稳定（避免匹配到子进程或旧残留）。
- 用 shell 命令快速查：
pgrep -f "myapp.*--mode=server"（加-f匹配完整命令行） - 在
launch.json里配合preLaunchTask，让 task 把 PID 写进临时文件，再用变量注入（VSCode 不原生支持动态 PID 替换，得靠外部脚本桥接） - 更简单省事的做法：在代码里加一句日志输出 PID，比如启动时打印
printf("PID: %d\n", getpid());，然后复制粘贴进launch.json - 别依赖
ps aux | grep myapp的输出位置——字段顺序可能变，pgrep或pidof更可靠
实际调试时最容易卡住的，是 program 路径和运行中进程的二进制不一致，以及 ptrace 权限被内核挡住——这两处没搞定，其他配置全对也连不上。
