Go中unsafe操作触发的SIGSEGV是OS层致命信号，Delve默认静默忽略，不暂停；需在launch.json中配置GODEBUG=sigpanic=1、-gcflags="-N -l"等参数才能使其转为可捕获panic并停在源码行。
段错误发生在 unsafe 操作时，GDB/VSCode 调试器为什么停不住？
因为 Go 的 unsafe 操作（比如 unsafe.Pointer 强转、uintptr 直接算地址、绕过 GC 的内存访问）触发的是底层 OS 信号（SIGSEGV），不是 Go runtime 的 panic。Delve 默认只拦截 panic 和用户断点，对 SIGSEGV 是“静默忽略”——程序直接崩溃退出，VSCode 连暂停机会都没有。
这不是配置漏了，是 Delve 的默认行为：它假设 SIGSEGV 是 fatal error，不介入。你看到的只是终端一闪而过的 signal: segmentation fault (core dumped)，调试器根本没机会响应。
- 必须在
launch.json中显式启用信号捕获："stopOnEntry": false不管用，要加"env": {"GODEBUG": "sigpanic=1"} - 更关键的是，在
args里传-gcflags "-N -l"—— 否则即使捕获到 SIGSEGV，符号表也缺失，堆栈显示为?? - 如果用了 cgo 或直接调
syscall.Mmap，还得加"env": {"CGO_ENABLED": "1"}，否则内存布局和 Delve 解析不一致
怎么让 VSCode 在 unsafe 崩溃那一行真正停住？
光靠断点没用——unsafe 导致的段错误往往发生在指针解引用瞬间（比如 (*int)(unsafe.Pointer(uintptr(0)))*），那行代码本身没有“可停”的执行点；Delve 只能在指令级停，但默认不暴露。
解决方案是强制 Delve 接管 SIGSEGV，并映射到源码行：
- 修改
launch.json的args字段，加入："-gcflags", "-N -l", "-ldflags", "-s -w"（-s -w减少干扰符号） - 在
env中添加："GODEBUG": "sigpanic=1"—— 这会让 Go runtime 把 SIGSEGV 转成可捕获的 panic - 确保你的
program指向可执行文件路径（如"${workspaceFolder}/bin/myapp"），而不是.go文件——Delve 对源码直跑的 SIGSEGV 支持弱 - 崩溃后，打开 “Call Stack” 面板，点最顶层帧，再点 “Variables” 查看寄存器值（
rax,rdi等），常能反推出哪个unsafe.Pointer被误用了
unsafe 场景下变量显示 <optimized out> 怎么办？
这不是优化问题，是 unsafe 绕过了 Go 编译器的变量生命周期管理。编译器无法推导出某块内存是否还“活着”，干脆不生成调试信息。
唯一可靠的做法是：把所有 unsafe 操作封装成独立函数，并在函数入口打日志或断点：
- 例如把
ptr := (*int)(unsafe.Pointer(&x))改成ptr := derefInt(&x)，并在derefInt第一行设断点 - 函数内加
fmt.Printf("derefInt: %p -> %v\n", &x, x)，配合调试器的 “Log Point”（右键断点 → Edit Breakpoint → Log Message） - 避免在循环体内反复做
unsafe计算——每次计算都可能因地址越界崩，且无法复现
用 GDB 验证 VSCode 里看不到的崩溃细节
VSCode + Delve 对 unsafe 的支持有局限，尤其涉及 mmap、共享内存或自定义 allocator 时。这时得切回原生 GDB：
- 先用
go build -gcflags="-N -l" -o myapp .编译 - 终端运行：
gdb ./myapp，然后run，崩了就输bt full看完整寄存器和内存状态 - 关键命令：
x/10xg $rsp（查栈顶 10 个 8 字节）、info registers（看rip是否落在runtime.sigpanic附近） - 如果
bt显示全是??，说明没符号——确认编译时加了-gcflags "-N -l"，且没 strip
Delve 是 Go 生态调试主力，但面对 unsafe，它只是“尽力而为”。真要深挖，GDB + 手动符号解析仍是不可替代的底线手段。
