必须先让程序运行至并发场景：dlv启动默认停在runtime.main，此时goroutine未调度，列表为空；需用break main.main再continue，或Ctrl+C中断已运行程序后执行goroutines才能获取完整快照。

dlv 调试时 goroutine 列表为空或不全怎么办

断点没触发前，goroutines 命令基本没用——dlv 启动后默认停在入口点（runtime.main），此时其他 goroutine 还没调度起来，列表自然为空或只有一两个。必须先让程序跑起来、触发真实并发场景。

• 用 break main.main 打断点，再 continue 运行到主函数开始；或直接 break <业务函数名>（如 break handleRequest）
• 程序已运行但没断住？按 Ctrl+C 中断，dlv 会进入调试态，这时再执行 goroutines 就能列出当前全部活跃 goroutine
• goroutines -t 5 可限制栈深度，避免输出刷屏；状态列里 waiting 表示阻塞，running 表示正在执行，syscall 多见于系统调用未返回

切换 goroutine 后查变量总不对，为什么

dlv 的上下文是“全局绑定”的：一旦执行 goroutine 17，后续所有 print、locals、stack 都作用于 ID 17 —— 但很多人切完不确认，回头查的还是上一个 goroutine 的变量。

• 切换前先执行 goroutine（不带参数），看当前 ID；切换后立刻再执行一次 goroutine，确认 ID 已变
• 局部变量可能被编译器优化掉，print v 报 could not find symbol 时，试试 print &v 或加编译参数 go build -gcflags="-N -l" 禁用优化
• 闭包变量不在 locals 里，得先 frame 0 切到栈顶帧，再用 print *(**int)(0x...) 解引用查看（地址从 info registers 或反汇编中找）

debug.PrintStack() 和 pprof.Lookup("goroutine").WriteTo() 有什么区别

debug.PrintStack() 只打当前 goroutine，轻量但视野窄；pprof.Lookup("goroutine").WriteTo(os.Stdout, 1) 输出全部 goroutine 的完整堆栈快照，适合定位死锁、泄漏或 goroutine 泄洪。

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

• debug.PrintStack() 必须导入 "runtime/debug"，输出无格式、无颜色，混在日志里容易被忽略；它不终止程序，适合临时埋点
• pprof.Lookup("goroutine").WriteTo(..., 1) 的第二个参数为 1 时显示全部 goroutine（包括系统 goroutine），为 2 时只显示用户创建的；注意它不包含变量值，只展示调用路径
• 想查阻塞原因？对 waiting 状态的 goroutine，用 print (*runtime.g)(17).waitreason（ID 替换为实际数字）可看到具体等什么（比如 semacquire 表示等信号量）

GDB 调试 Go 时变量显示为 <optimized out&gt> 怎么办

Go 编译器默认开启内联和逃逸分析，导致局部变量被优化掉或移入堆，GDB 就找不到符号。这不是 GDB 的问题，而是编译选项没配对。

立即学习“go语言免费学习笔记（深入）”；

• 编译时必须加 go build -gcflags="-N -l"：-N 禁用优化，-l 禁用内联，否则 GDB 查不到变量、断点也可能偏移
• 不要用 go run 调试，它临时编译不保留调试信息；始终用 go build 生成二进制再调试
• GDB 中 info locals 显示空？试试 info registers 看寄存器值，或 x/10i $pc 查当前指令，结合源码定位真实变量位置

实际调试时，最常卡住的地方不是命令不会输，而是没意识到上下文切换是持久的、变量是否存活取决于编译参数、以及 waiting 状态背后的真实阻塞点需要额外指令才能挖出来。