17370845950

channel 必须初始化才能使用：声明

chan int 类型变量未用 make 初始化，运行时 panic 报「send on nil channel」；Go 禁止对 nil channel 发送或接收数据。

channel 必须初始化才能使用

声明一个 chan int 类型变量但没用 make 初始化，运行时会 panic：「send on nil channel」。Go 不允许对 nil channel 发送或接收数据。

• 错误写法：

  var ch chan int
  ch <- 42 // panic!

• 正确写法：

  ch := make(chan int, 0) // 无缓冲
  // 或
  ch := make(chan int, 10) // 缓冲容量为 10

• 缓冲区大小为 0 表示同步 channel，发送和接收必须配对阻塞；非 0 表示异步，发送方在缓冲未满时不阻塞

用 select + default 避免死锁和忙等

单独对 channel 调用 可能永远阻塞（比如 sender 已退出），而纯 select 没 default 也会卡住。实际并发控制中，常需非阻塞探测或超时处理。

• 非阻塞读取：

  select {
  case v := <-ch:
      fmt.Println("received", v)
  default:
      fmt.Println("channel empty, no block")
  }

• 带超时的接收：

  select {
  case v := <-ch:
      fmt.Println("got", v)
  case <-time.After(1 * time.Second):
      fmt.Println("timeout")
  }

• 多个 channel 同时监听时，select 随机选择一个就绪分支；若多个就绪，不会按书写顺序执行

关闭 channel 后不能再发送，但可继续接收

关闭 channel 的唯一合法操作是调用 close(ch)，且仅应由 sender 执行。receiver 侧可通过多值接收判断是否已关闭：v, ok := 中 ok 为 false 表示 channel 已关且无剩余数据。

• 错误：关闭后还发数据 —— ch 会 panic
• 安全接收习惯：

  for v := range ch {
      process(v)
  }
  // 等价于：
  for {
      v, ok := <-ch
      if !ok {
          break
      }
      process(v)
  }

• 不要用 close 当作“信号”来通知 receiver 停止 —— 它只表示“不再有新数据”，receiver 仍可能从缓冲中读出若干值

channel 不是万能锁，别用它替代 sync.Mutex

有人误以为「用 channel 控制单个 goroutine 串行访问共享变量」就是线程安全，但这是错觉。channel 传递的是值拷贝，若结构体含指针或 map/slice，仍可能引发 data race。

• 危险示例：

  type Counter struct{ n *int }
  ch := make(chan Counter, 1)
  go func() { ch <- Counter{n: &x} }() // 发送指针
  go func() { c := <-ch; *c.n++ }()     // 并发改同一地址 → race

• 真正需要保护共享内存时，优先用 sync.Mutex 或 sync.RWMutex
• channel 更适合解耦生产者/消费者、传递所有权、协调生命周期（如 done channel），而不是做细粒度状态同步

关闭 channel 的时机、缓冲区大小的选择、select 分支的公平性，这些细节不写日志很难复现问题。尤其在嵌套 goroutine 和多层 channel 转发时，漏关、重复关、错关都会导致 hang 或 panic。