Go singleflight中为何在有chans时使用go panic而非直接panic？

针对你提出的三个问题，逐一拆解如下：

1. 为何存在channel时用go panic(e)而非直接panic(e)？ #

当len(c.chans) > 0时，说明有其他goroutine在等待当前请求的结果。此时选择启动新goroutine触发panic，核心原因有两点：

• 避免僵尸goroutine永久阻塞：如果直接panic，当前执行docall的goroutine会立即终止，而等待的goroutine会一直阻塞在<-ch操作上（无人向这些channel发送结果）；若上层调用者用recover捕获了panic，程序会继续运行，导致这些阻塞的goroutine永久占用资源。而新goroutine触发的panic无法被上层recover捕获，会直接导致程序崩溃，所有goroutine都会被清理，不会留下僵尸资源。
• 保留崩溃现场便于排查：当前goroutine通过select{}挂起，会保留在崩溃dump中，结合新goroutine的panic信息，能清晰看到是哪个请求触发了panic，以及有哪些goroutine在等待该请求的结果。

2. 若docall在独立goroutine中执行（第129行go docall），go panic(e)是否有意义？ #

完全有意义：

• 若docall在独立goroutine中运行，直接panic(e)只会终止该goroutine，上层调用者无法捕获这个panic（goroutine间panic隔离），导致等待的goroutine永久阻塞，程序却仍在运行，引发资源泄漏。
• 而go panic(e)启动的新goroutine会触发全局panic，直接终止整个程序，彻底清理所有阻塞的goroutine，避免资源泄漏，同时保留完整的崩溃现场，方便定位问题。

3. 并发请求下，panic后未写入channel，其他goroutine是否会陷入阻塞？ #

会，但这是设计有意为之：

• 当触发panic时，说明请求处理逻辑出现了严重错误，此时程序已不具备正常服务的能力。与其让部分goroutine永久阻塞、占用资源，不如让程序直接崩溃，强制终止所有goroutine，避免更严重的资源泄漏问题。同时，崩溃dump会完整保留所有goroutine的状态，便于开发者快速定位panic根源和受影响的请求。

内容的提问来源于stack exchange，提问作者whutsol