解读

国内一线/二线厂对 Go 并发模型考察极细，“double-close panic” 是高频踩坑点。面试官不仅想看你知道“不能重复 close”，更在意你能否：

1. 在测试阶段提前发现，而不是上线后靠 panic 日志回捞；
2. 用自动化工具快速定位哪一行、哪个 goroutine 写了第二次 close；
3. 给出工程级防重方案，而非临时打补丁。

因此，回答要围绕“检测工具 + 定位流程 + 防重策略”三层展开，体现你对 go test、race、静态分析链路的熟悉度。

知识点

1. channel 关闭语义：仅允许一次 close，第二次触发 panic: close of closed channel。
2. panic 栈回溯默认只到触发点，若代码经过封装（pool、util 包）很难一眼看出“第一次关闭”是谁。
3. double-close 检测工具：
   • go test -race：能捕获“并发 close”数据竞态，但对“串行 double-close”不敏感；
   • go.uber.org/goleak：主要查 goroutine 泄漏，不查 double-close；
   • github.com/sasha-s/go-deadlock：可插拔锁检测，可扩展为“channel close 钩子”；
   • 静态分析：go vet -unsafeptr 不会查 channel；需自写 go/analysis 插件或复用 nilness/cmd/vetnil 思路做“close 路径”计数；
   • 运行时注入：用 build tag 打桩 runtime.closechan，在测试二进制里插入计数器，重复关闭时打印第一次关闭的 goroutine ID + 文件行号。
4. 工程落地：把检测逻辑封装成 //go:build debug 的测试桩，CI 阶段自动跑，发布阶段自动剔除，零性能损耗。

答案

线上若已 panic，先保留现场：

1. 在 Grafana/ELK 里捞到 panic: close of closed channel 的完整栈；
2. 用 dlv core 加载生成的 core 文件，执行 goroutines -t 查看所有 goroutine 的 channel 句柄；
3. 若未开 core，则本地复现：对可疑测试用例加 go test -race -v，race 检测器会打印“which goroutine closed first”的堆栈，90% 场景可直接定位；
4. 若 race 未触发（串行 close），引入 double-close 检测桩：

// +build debug

package chdebug

import "sync"

var closed = make(map[chan struct{}]string)
var mu sync.Mutex

func SafeClose(c chan struct{}) {
    mu.Lock()
    loc, done := closed[c]
    mu.Unlock()
    if done {
        panic("double-close detected, first at:\n" + loc)
    }
    close(c)
    mu.Lock()
    _, file, line, _ := runtime.Caller(1)
    closed[c] = fmt.Sprintf("%s:%d", file, line)
    mu.Unlock()
}

把代码里所有 close(ch) 换成 chdebug.SafeClose(ch)，单元测试跑一次即可打印第一次关闭位置； 5. 修复方案：用 sync.Once 或 context.CancelFunc 保证唯一关闭权，或者把“关闭权”收敛到单 goroutine 所有权模型，彻底杜绝 double-close。

拓展思考

1. 生产环境零侵入检测：利用 eBPF + uprobe 挂 runtime.closechan，把事件发到 Kafka，再与代码行号映射表关联，实现在线 double-close 实时告警，字节跳动内部已落地。
2. 泛化到 generic channel：Go1.18 泛型后，可把 SafeClose 写成 SafeClose[T any](ch chan T)，一套代码检测所有类型 channel。
3. 与 race 检测器互补：race 只能发现“并发 close”，对“串行 double-close”无能为力；因此CI 流水线里应同时跑 go test -race 与 自定义 double-close 桩，双保险。
4. ownership 文档化：在代码审查模板里强制回答“谁负责关闭”，把 channel 生命周期写进 go doc，从源头降低 double-close 概率，这也是国内大厂代码评审的硬门槛之一。