pstack不可用时，gdb -p -ex "thread apply all bt" -ex "detach" -ex "quit"是最稳的实时抓栈方式，因其可主动detach避免卡死进程，且能手动处理调试符号路径、绕过ptrace_scope限制。
pstack 不能用时，直接上 gdb -p 是最稳的实时抓栈方式，但必须加 detach 避免卡死进程。
为什么不用 pstack 而选 gdb -p
pstack 看似简单，实际常失败：进程在 D 状态时 attach 直接报 Cannot attach to process；普通用户查别人进程会遇到 Permission denied；Ubuntu/Debian 默认开启 ptrace_scope=1，连自己启的容器进程都可能 attach 不上。而 gdb -p 同样依赖 ptrace，但它能手动控制流程——attach → 打印 → detach → 退出，全程不阻塞业务。
关键点在于：gdb -p <pid> -ex "thread apply all bt" -ex "detach" -ex "quit"</pid> 这条命令里 detach 不可省略，否则 gdb 会一直 hold 住进程，导致请求超时或连接堆积。
gdb -p 抓栈前必须确认的三件事
不是所有 gdb -p 都能打出有意义的栈：
- 目标进程的可执行文件得带调试符号，或系统有对应
.debug包（如libstdc++-debuginfo），否则大量??()； -
file /proc/<pid>/exe</pid>输出里要有with debug_info或类似字样，没这个基本白忙； - 若进程用了自定义路径的 so（比如
/opt/myapp/libcurl.so.4），gdb 默认找不到它的 debug 文件，得手动指定：set debug-file-directory /usr/lib/debug:/opt/myapp/.debug。
多线程 C++ 进程栈里全是 ??() 怎么办
这不是二进制没加 -g，而是运行时链接的库缺调试符号。常见组合：
-
libstdc++.so缺libstdc++-debuginfo（CentOS/RHEL）或libstdc++6-dbgsym（Ubuntu）； -
libc.so.6缺libc6-dbg（Debian/Ubuntu）； - 第三方库（如
libgrpc.so）是自己编译的，但没保留.debug文件，或没安装到/usr/lib/debug下； - pstack 完全忽略
~/.gdbinit，所以你在里面配的set debug-file-directory对它无效，只能在 gdb 命令行里显式设。
静态链接程序（Go、Rust 默认）别硬套 gdb -p
Go 二进制默认静态链接，gdb -p 只能看到 runtime 的汇编帧，main.main 以下全是 ??()；Rust 同理，除非你显式加了 debug = true 且没 strip。这种场景下：
- Go 程序优先发
kill -SIGUSR1 <pid></pid>，触发 runtime 自打印 goroutine stack 到 stderr； - 或者用
go tool pprof -e http://localhost:6060/debug/pprof/goroutine?debug=2； - Rust 程序可启用
backtrace=1环境变量，或用addr2line手动解析地址（需保留.dwp或.debug）。
强行用 gdb 查 Go，看到的 runtime.mcall 和 runtime.goexit 并不能帮你定位业务逻辑卡点——那是语言运行时的抽象层，不是你的代码。
