不能，但 go vet 和 linter 可捕获部分模式：Go 编译器不检查死锁，go build 成功不代表无死锁；go vet 识别未使用 channel、空 select 等显式模式，golangci-lint 配合插件可发现向未启动接收协程的无缓冲 channel 发送等高危写法。
编译期能检测到死锁吗？不能，但 go vet 和 linter 可捕获部分模式
Go 编译器本身不检查死锁，go build 成功不代表无死锁。真正起作用的是静态分析工具：go vet 对未使用的 channel、空 select、未关闭的循环 goroutine 有基础识别；golangci-lint 配合 deadcode、nilness、staticcheck 插件，能发现如「向未启动接收协程的无缓冲 channel 发送」这类高危写法。
常见误判点：
-
go vet不报错 ≠ 安全 —— 它只覆盖显式可推断的死锁模式（比如函数内单 goroutine 向 unbuffered chan 发送后无接收） -
golangci-lint默认不启用govet的全部检查项，需显式开启：--enable=vet - 第三方 linter 如
errcheck或unused无法替代死锁逻辑分析，它们关注错误处理或变量使用，而非阻塞路径
高可用环境必须启用 -race，但它不是编译期检测
go run -race 或 go test -race 是运行时竞争检测器，它能暴露 channel 操作间的竞态和潜在死锁链（例如 goroutine A 等 B 关闭 channel，B 等 A 发送完成），但代价是性能下降 2–5 倍、内存占用翻倍。它不会在编译阶段报错，而是在程序执行中触发 panic 并打印堆栈。
关键限制：
立即学习“go语言免费学习笔记（深入）”；
- 仅对实际执行到的代码路径有效 —— 未触发的分支、条件化启动的 goroutine 不会被检测
- 无法识别纯逻辑死锁（如两个 goroutine 互相等待对方发信号，但信号本身从未定义发送条件）
- CI/CD 中建议仅对核心集成测试启用，避免拖慢构建流程
pprof + /debug/pprof/block 是定位死锁最准的手段
当线上服务卡住、CPU 归零、fatal error: all goroutines are asleep - deadlock! 却没复现时，/debug/pprof/block 能直接告诉你哪些 goroutine 在等什么资源。它统计的是阻塞在同步原语（channel send/recv、mutex、semaphore）上的调用栈，比单纯看 goroutine 列表更聚焦。
实操要点：
- 必须提前在服务中导入
_ "net/http/pprof"并启动 HTTP server（哪怕只监听 localhost） -
/debug/pprof/block?debug=1显示阻塞时间最长的 top N 调用，优先排查耗时 >1s 的条目 - 注意区分：channel 阻塞显示为
runtime.gopark+chan send或chan recv；mutex 阻塞则带sync.(*Mutex).Lock
真正预防死锁，靠的是编码契约而非工具
所有工具都是事后补救。高可用系统里最有效的预防，是把死锁约束变成团队共识和代码规范：
- 无缓冲 channel 的发送方，必须确保接收方 goroutine 已启动且未退出 —— 不能靠「应该会有人收」这种假设
- 谁创建 channel，谁负责 close；多个 sender 时，由协调者（非任意 worker）用
sync.WaitGroup控制关闭时机 - 禁止在
main()函数里直接向 unbuffered chan 发送 —— 这是微服务启动即死的头号原因 - 所有 channel 操作必须包裹在
select中，至少含一个default或time.After分支，杜绝无限等待
工具再强，也救不了没写接收逻辑的 channel；跑得再快的 race detector，也测不出根本没跑的 goroutine。死锁不是技术问题，是协作契约没落地的问题。
