当匿名 goroutine 向无缓冲通道发送数据而无人接收时，该 goroutine 将永久阻塞；若主函数已返回，这些 goroutine 不会被自动回收，持续占用内存与调度资源，形成典型的 goroutine 泄漏。

当匿名 goroutine 向无缓冲通道发送数据而无人接收时，该 goroutine 将永久阻塞；若主函数已返回，这些 goroutine 不会被自动回收，持续占用内存与调度资源，形成典型的 goroutine 泄漏。

在 Go 中，goroutine 是轻量级执行单元，但并非无成本——每个 goroutine 默认分配 2KB 栈空间，并受运行时调度器管理。一旦进入阻塞状态（如向无人接收的无缓冲 channel 发送），它不会被垃圾回收器（GC）清理，也不会因所属函数（如 foo）返回而自动终止。

以原始示例为例：

foo()

• 使用带缓冲通道（适合已知最大发送数）：

  ch := make(chan string, 10) // 容纳全部10个写入，永不阻塞发送端

• 引入上下文（Context）控制生命周期（推荐用于动态或长期运行场景）：

  func foo(ctx context.Context) string {
      ch := make(chan string, 1)
      for i := 0; i 

• 显式关闭通道 + range + done channel（适用于需处理全部结果的场景）：

  func foo() []string {
      ch := make(chan string, 10)
      done := make(chan struct{})
      go func() {
          for i := 0; i 

⚠️ 注意事项：

• Go 的 GC 不回收正在运行或阻塞的 goroutine，无论其是否“孤立”；
• defer、函数作用域结束、变量逃逸均不影响 goroutine 生命周期；
• 使用 pprof（go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=1）可实时诊断 goroutine 泄漏；
• 生产环境应始终为并发操作设计超时、取消或容量边界，避免隐式无限等待。

总结：Go 不提供“自动终结僵尸 goroutine”的机制。开发者必须主动管理并发生命周期——这是写出健壮并发程序的关键责任。