本文揭示 go 语言中因未调用 make 初始化通道（channel）而导致发送操作永久阻塞的根本原因，并通过代码对比、运行机制分析和最佳实践，帮助开发者快速定位与规避此类常见陷阱。
本文揭示 go 语言中因未调用 make 初始化通道（channel）而导致发送操作永久阻塞的根本原因，并通过代码对比、运行机制分析和最佳实践，帮助开发者快速定位与规避此类常见陷阱。
在 Go 并发编程中，通道（channel）是协程间安全通信的核心机制。但一个极易被忽视的底层规则是：所有通道变量在使用前必须显式初始化——即通过 make(chan T) 创建底层数据结构；否则其值为 nil，对 nil 通道的任何发送或接收操作都会永久阻塞，且不会触发 panic 或超时。
回顾原始代码的问题所在：
var resp chan string // ❌ 未初始化：resp == nil
func send() {
ticker := time.NewTicker(10 * time.Second)
select {
case <-ticker.C:
log.Println("Sending")
resp <- "Message" // ⚠️ 阻塞在此：向 nil channel 发送，goroutine 永久挂起
}
}此处 resp 是一个零值通道变量，其底层指针为 nil。根据 Go 规范，对 nil 通道执行发送操作会令当前 goroutine 进入不可恢复的等待状态（等效于 select {}），整个程序因此“卡死”。
✅ 正确做法是使用 make 显式创建带缓冲或无缓冲通道：
package main
import (
"log"
"time"
)
var resp = make(chan string) // ✅ 初始化为无缓冲 channel
func main() {
go send()
listen()
}
func listen() {
select {
case response := <-resp:
log.Printf("Writing response: %s\n", response)
}
}
func send() {
ticker := time.NewTicker(10 * time.Second)
defer ticker.Stop() // ? 好习惯：避免资源泄漏
<-ticker.C // 等待第一次滴答
log.Println("Sending")
resp <- "Message" // ✅ 成功发送，listen goroutine 将收到并退出
}? 关键提示：
- 无缓冲通道要求发送与接收操作同步配对；若 listen() 未就绪，send() 仍会阻塞（这是正常行为）。本例中 listen() 在主 goroutine 中执行且位于 send() 启动之后，因此能及时接收。
- 若需解耦发送与接收时机（如长轮询场景），建议使用带缓冲通道：make(chan string, 1)，可暂存一条消息，避免发送端因接收端延迟而阻塞。
- 始终检查通道变量是否为 nil（尤其在复杂初始化逻辑中），可通过 if resp == nil { log.Fatal("channel not initialized") } 辅助调试。
总结：Go 的通道不是“声明即可用”的语法糖，而是需主动构造的运行时对象。牢记 “声明 ≠ 初始化” —— 所有 chan、map、slice 类型均需 make（或字面量）初始化，否则将引发静默阻塞或 panic。养成初始化即赋值的习惯（如 var resp = make(chan string) 或 resp := make(chan string)），是编写健壮并发程序的第一道防线。
