Go程序默认不生成core文件是设计使然，因其panic由runtime自主处理并exit(2)，绕过内核信号机制；仅Cgo崩溃等非原生场景才可能触发core，需配合系统配置、syscall.Setrlimit、GOTRACEBACK=crash及dlv调试。
Go 程序默认不生成 core 文件，这不是 bug，是设计使然
你执行 ulimit -c unlimited、改了 /proc/sys/kernel/core_pattern、甚至用 GOTRACEBACK=crash，结果目录下还是没 core——不是环境没配对，是 Go 原生 panic 根本不走内核信号路径。它靠 runtime 自己展开栈、打印堆栈、然后 exit(2)，全程绕过 SIGABRT/SIGSEGV，所以内核压根收不到 dump 请求。
- 只有非 Go 原生崩溃才可能触发 core：比如
Cgo里调abort()、free(NULL)、或手动raise(SIGSEGV) -
CGO_ENABLED=0时连syscall.Setrlimit都调不了，ulimit -c彻底失效，core 生成能力归零 - 想确认是否真有 core 可能性？先跑个带 C 调用的测试：用
C.malloc(0)+C.free(nil)触发段错误，再看/tmp/core*
让非原生 panic 生成 core 的三步实操
目标很明确：让 C 层崩溃落地为可被 gdb 或 dlv 加载的 core 文件。这需要系统层、Go 层、运行时三层配合。
- 设好系统 core 路径：
echo '/tmp/core-%e.%p' | sudo tee /proc/sys/kernel/core_pattern - 开大资源限制：
ulimit -c unlimited（注意检查硬限制：ulimit -H -c，为 0 就得改/etc/security/limits.conf） - 在
main()最开头加启用代码：syscall.Setrlimit(syscall.RLIMIT_CORE, &syscall.Rlimit{Cur: ^uint64(0), Max: ^uint64(0)}) - 必须配
GOTRACEBACK=crash：它会让 panic 最后主动 raiseSIGABRT，这是唯一能让 Go 主动“交出控制权”给内核 dump 的方式
用 dlv 分析 core 比 gdb 更靠谱
gdb 能打开 core，但看到的往往是 runtime.sigtramp 或空栈帧——因为 goroutine 栈不在 libc 栈上，gdb 不认识 Go 的调度器布局和栈结构。而 dlv 是专为 Go 设计的调试器，能识别 goroutine、M、P 状态，也能还原符号。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 编译时禁用优化：
go build -gcflags="all=-N -l" -o app ./main.go（-N关优化，-l关内联，否则变量名和行号会丢） - 别加
-ldflags="-w"：它会 strip 调试信息，dlv就读不到源码上下文 - 加载 core：
dlv core ./app /tmp/core-app.12345 - 进去了先输
goroutines看所有协程，再gr 1切到目标 goroutine，bt查调用链，locals看局部变量
真正该盯住的不是 core，而是 panic 前那几秒
大多数线上 panic 是偶发、难复现、无日志上下文的。等 core 出来再分析，往往用户输入、网络请求、时间点都丢了。与其赌 core 是否生成成功，不如在 panic 发生前就把现场“快照”下来。
立即学习“go语言免费学习笔记（深入）”；
- 启动时设
runtime.SetTraceback("system")或环境变量GOTRACEBACK=all，让 panic 输出含寄存器、SP、PC 和所有 goroutine - 关键入口加
defer捕获栈：buf := make([]byte, 1024*1024); runtime.Stack(buf, true)写入日志文件 - 服务类程序直接暴露
/debug/pprof/goroutine?debug=2，panic 前手动 curl 一把，拿到全量 goroutine 状态 - 工具类程序用
go tool trace录制最后 5 秒：启动时加runtime/trace.Start，panic 前trace.Stop()写磁盘
core 是兜底手段，不是首选路径。尤其在容器、Alpine、CGO_DISABLED 环境下，它大概率根本不会出现。把可观测性埋进代码里，比等一个不确定的文件更可靠。
