Go不支持手动线程管理，goroutine由运行时自动调度；主goroutine退出会导致程序终止，需用WaitGroup或Context显式等待子goroutine完成，避免依赖time.Sleep、channel泄漏及goroutine泛滥。
Go 本身不支持“多线程编程”意义上的手动线程管理，goroutine 不是线程，也不是对 pthread 的封装——它压根不让你碰线程。所谓“Golang框架如何多线程”，本质是误用术语；真正该问的是：**怎么安全、可控、可观察地调度大量 goroutine，并让它们协同完成任务**。
goroutine 创建后立刻退出？主函数没等它
最常见现象：加了 go 关键字，但程序一闪而过，什么都没打印。这不是并发失败，是主 goroutine 执行完直接退出进程，其他 goroutine 被强制终止。
- 别依赖
time.Sleep做同步——它不可靠，时长难估，且掩盖了真正的协调逻辑 - 优先用
sync.WaitGroup显式等待：在启动前wg.Add(1)，结束时wg.Done()，最后wg.Wait() - 若需带超时控制，用
context.WithTimeout包裹，配合select监听ctx.Done()
channel 阻塞导致 goroutine 泄漏？缓冲区和关闭逻辑没配对
写入无缓冲 channel（make(chan int)）时，若没有 goroutine 同时读，发送方会永久阻塞；有缓冲但容量满、又没人读，同样卡住。这类阻塞不会报错，但 goroutine 永远无法退出，形成泄漏。
- 无缓冲 channel 只适合点对点同步通信，确保收发双方都就绪再操作
- 有缓冲 channel（如
make(chan int, 10)）能缓解生产消费速度差，但必须配对使用：close()后，接收方才能通过for range安全退出 - 切忌在多个 goroutine 中重复
close()——会 panic：panic: close of closed channel - 不确定谁该关 channel？按职责划分：通常是数据生产者关闭，消费者只读
高并发下 goroutine 数量失控？没设边界也没回收机制
一个 HTTP handler 里写 go handleRequest()，每秒 1000 请求就起 1000 个 goroutine；若处理慢或下游超时，这些 goroutine 会长时间堆积。内存涨、调度延迟上升、runtime.NumGoroutine() 持续飙升，就是典型信号。
立即学习“go语言免费学习笔记（深入）”；
- 不要裸写
go f()处理请求级任务，尤其涉及 I/O 或外部调用 - 用 worker pool 控制并发上限：固定数量的长期运行 goroutine 从
jobschannel 拿任务，避免瞬时爆发 - 设置
runtime.GOMAXPROCS(n)通常没必要——默认已设为 CPU 核数；真正要调的是 worker 数量，不是 P 数 - 上线前加监控：定期打点
runtime.NumGoroutine()，突增或缓慢爬升都需排查
goroutine 和 channel 的组合不是魔法，它把“调度权”交还给运行时，但把“责任”留给了你：谁启、谁等、谁关、谁限。最容易被忽略的，从来不是语法，而是每个 go 后面，是否明确知道这个 goroutine 的生命周期由谁终结、在什么条件下终结、资源是否彻底释放。
