如何在测试中捕获程序产生的崩溃堆栈信息

学习Golang要努力，但是不要急！今天的这篇文章《如何在测试中捕获程序产生的崩溃堆栈信息》将会介绍到等等知识点，如果你想深入学习Golang，可以关注我！我会持续更新相关文章的，希望对大家都能有所帮助！

Go测试中panic无堆栈主因是recover未打印、os.Exit提前退出或子进程隔离；应defer+recover后调用debug.PrintStack，子进程需设GOTRACEBACK=crash。

崩溃时没堆栈？先确认 panic 捕获是否被禁用

Go 程序默认 panic 会打印完整堆栈并退出，但测试中常因 recover()、os.Exit() 或子进程隔离导致堆栈丢失。关键不是“怎么捕获”，而是“为什么没看到”。

• 检查测试函数里有没有裸调用 recover() 却没打印 debug.PrintStack() 或 runtime.Stack()
• 避免在 TestMain 中用 os.Exit(0) 提前终止——这会让 panic 堆栈直接丢弃
• 子进程（如 exec.Command）崩溃时，父进程只能拿到 exit code，堆栈需在子进程中显式输出到 stderr

Go 测试中正确捕获 panic 堆栈的写法

别依赖外部工具或重定向 stderr，Go 自带机制足够可靠。重点是让 panic 发生在当前 goroutine，并主动提取堆栈。

• 用 defer + recover() 捕获后，立刻调用 runtime/debug.PrintStack()（输出到 stdout）或 runtime/debug.Stack()（返回 []byte）
• 若要断言 panic 内容，推荐用 testify/assert.Panics 或原生 assert.Panics，它们内部已处理堆栈捕获
• 注意：runtime.Stack() 默认只抓当前 goroutine；加第二个参数 true 才获取所有 goroutine 堆栈（测试中一般不需要）

func TestCrashWithStack(t *testing.T) {
	defer func() {
		if r := recover(); r != nil {
			t.Log("panic occurred:")
			debug.PrintStack() // 这行确保堆栈进测试日志
			t.FailNow()
		}
	}()
	badFunc() // 触发 panic 的函数
}

非 Go 语言？C/C++/Rust 测试崩溃堆栈要绕开信号屏蔽

很多测试框架（如 Catch2、gtest、cargo test）默认屏蔽 SIGSEGV 或 SIGABRT，导致崩溃不产生 core dump 或堆栈。不是代码问题，是环境配置问题。

• C/C++ 测试中，运行前加 ulimit -c unlimited 并确保 /proc/sys/kernel/core_pattern 可写，否则 gdb -c core 打不开
• Rust 的 cargo test 默认关闭 panic 堆栈（RUST_BACKTRACE=0），必须显式设为 1 或 full
• CI 环境常禁用 core dump，此时应改用 addr2line + objdump 解析 panic 地址，而不是等自动堆栈

日志里只有 “exit status 1”？说明崩溃发生在子进程

这是最常被误判的场景：你以为程序 panic 了，其实只是子进程 crash，主进程只收到一个状态码。堆栈根本没传出来。

• 用 cmd.CombinedOutput() 而非 cmd.Output()，确保 stderr 不丢失
• 子进程启动时加 GOTRACEBACK=crash（Go）、RUST_BACKTRACE=1（Rust）等环境变量，强制崩溃时输出堆栈到 stderr
• 如果子进程是 C 程序，用 setrlimit(RLIMIT_CORE, ...) 开启 core dump，并在测试后用 gdb --batch -ex "bt" ./binary core 提取堆栈

崩溃堆栈不是总能自动出现，它高度依赖 panic 是否被拦截、信号是否被屏蔽、进程是否被隔离。最容易忽略的是子进程场景——你看到的 exit code，往往就是全部信息了。

以上就是《如何在测试中捕获程序产生的崩溃堆栈信息》的详细内容，更多关于的资料请关注golang学习网公众号！