我将在这里使用 go version devel go1.17-d19a53338f Wed Jun 30 02:00:49 2021 +0000 linux/amd64 作为示例，但这也适用于 1.16.5。
从 https://golang.org/pkg/runtime/ 中，强调我的部分：
GOTRACEBACK 变量控制了当 Go 程序因未恢复的恐慌或意外运行时条件而失败时生成的输出量。默认情况下，失败会为当前 goroutine 打印堆栈跟踪,省略运行时系统内部的函数，然后以退出代码 2 退出。
所以看起来，默认情况下，panic 应该只打印发生 panic 的 goroutine 的堆栈跟踪，其他什么也不用。
然而，在某些情况下，这似乎并不正确：https://play.golang.org/p/zWw2TUS4YzZ

$ go run -trimpath f.go
fatal error: concurrent map writes

goroutine 7 [running]:
runtime.throw({0x467980, 0x0})
	runtime/panic.go:1198 +0x71 fp=0xc00003cf78 sp=0xc00003cf48 pc=0x42cb91
runtime.mapassign_fast64(0x45f100, 0xc000072060, 0x2)
	runtime/map_fast64.go:176 +0x2b4 fp=0xc00003cfb0 sp=0xc00003cf78 pc=0x40dcb4
main.main.func3()
	./f.go:12 +0x2e fp=0xc00003cfe0 sp=0xc00003cfb0 pc=0x45814e
runtime.goexit()
	runtime/asm_amd64.s:1581 +0x1 fp=0xc00003cfe8 sp=0xc00003cfe0 pc=0x453dc1
created by main.main
	./f.go:10 +0x85

goroutine 1 [sleep]:
time.Sleep(0x3b9aca00)
	runtime/time.go:193 +0x12e
main.main()
	./f.go:21 +0xd1

goroutine 5 [sleep]:
time.Sleep(0xdf8475800)
	runtime/time.go:193 +0x12e
main.main.func1()
	./f.go:6 +0x25
created by main.main
	./f.go:6 +0x26

goroutine 6 [sleep]:
time.Sleep(0xdf8475800)
	runtime/time.go:193 +0x12e
main.main.func2()
	./f.go:7 +0x25
created by main.main
	./f.go:7 +0x34

goroutine 8 [runnable]:
main.main.func4()
	./f.go:17 +0x2e
created by main.main
	./f.go:15 +0xc7
exit status 2

根据文档，我本应该只看到一个 goroutine 堆栈转储 - 通过 runtime.mapassign_fast64 触发的 "运行" goroutine,但我得到了所有的堆栈转储。
这似乎是代码故意这样设计的：
go/src/runtime/panic.go
d19a533 中的第 1385 行到第 1399 行
| | ifgp!=gp.m.curg { |
| | all=true |
| | } |
| | ifgp!=gp.m.g0 { |
| | print("
") |
| | goroutineheader(gp) |
| | traceback(pc, sp, 0, gp) |
| | } elseiflevel>=2||g.m.throwing>0 { |
| | print("
runtime stack:
") |
| | traceback(pc, sp, 0, gp) |
| | } |
| | if!didothers&&all { |
| | didothers=true |
| | tracebackothers(gp) |
| | } |
这有两个问题：
A:令人困惑。当我查看 Go 进程崩溃输出和运行时文档时，这让我感到困惑。
B:它可能导致大量的 panic 输出，具体取决于运行哪种 panic。在工作中，有人非常惊讶地发现一个 panic 导出了约 50MiB 的 goroutine 堆栈，而大多数其他 panic 只导出一个 goroutine 堆栈。实际上导致了基础设施问题，因为我们的日志摄取似乎不太喜欢这种突然的输出大量，我们从未找到过原因，因为大多数 panics 不这样做。
我对这个问题有三个可能的解决方案：
1.代码按预期工作。我们应该更新文档以澄清默认情况下会在某些情况下打印所有 goroutine 堆栈跟踪的细微差别，以及这些情况是什么。
1.我们应该修改实现以匹配文档。并发Map写入应导致仅打印一个堆栈跟踪的 panic,即上面的 "运行" goroutine。
1.介于两者之间，例如 "打印涉及要查询的Map的所有 goroutines 的堆栈跟踪"。我可以想象当前行为存在调试目的：如果您遇到并发Map写入，您可能想知道那些两个或更多的 goroutine 在做什么，而不仅仅是其中一个。然而，您可能不需要 所有 goroutines;只需要涉及竞争的那些。