复用goroutine可降低开销，使用worker pool配合带缓冲的channel处理高频短任务，避免频繁创建。
Go语言中goroutine的创建成本虽低，但高频创建仍会带来可观的内存分配、调度器注册、栈初始化等开销。真正减少开销的关键不是“少用goroutine”，而是避免无意义的重复创建，并让goroutine复用起来。
复用goroutine：用worker pool替代即时启动
高频短任务（如HTTP请求处理、消息解析）若每次新建goroutine，会快速堆积调度压力和GC负担。改用固定数量的worker goroutine配合channel接收任务，可显著降低创建频次。
- 定义带缓冲的任务channel，例如 jobs := make(chan Task, 1024)
- 启动固定数量worker（如CPU核心数的2–4倍），每个worker在for-select循环中持续取任务执行
- 提交任务只需 jobs ，无需go doTask(task)
避免闭包捕获导致的堆逃逸
当goroutine中使用外部变量（尤其是大结构体或切片），编译器可能将变量抬升到堆上，触发额外分配。这虽不直接增加goroutine创建开销，但放大了整体内存压力，间接拖慢调度。
- 显式传参代替隐式捕获：go func(x int) { ... }(v) 比 go func() { ... }() 更安全
- 对小而确定的数据，优先用值传递；大对象考虑传指针+加锁保护，而非依赖闭包捕获
合理设置GOMAXPROCS与runtime.GOMAXPROCS
过多P（逻辑处理器）不会加速goroutine创建，反而增加调度器维护成本。默认GOMAXPROCS已设为系统逻辑核数，除非明确需要（如I/O密集型混合计算），否则不建议手动调高。
- 可通过 runtime.GOMAXPROCS(0) 查询当前值
- 上线前用GODEBUG=schedtrace=1000观察调度器行为，确认P数是否稳定、有无大量goroutine排队
慎用time.AfterFunc与类似封装
time.AfterFunc(d, f) 内部每次都会新建goroutine。若用于高频定时（如每10ms刷新状态），应改用单个goroutine + for-select + time.Ticker。
- 错误写法：for { time.AfterFunc(time.Millisecond*10, update) } → 每次都新启goroutine
- 正确写法：启动一个goroutine，内含 ticker := time.NewTicker(10 * time.Millisecond); defer ticker.Stop()，在循环中select接收
基本上就这些。goroutine本身轻量，但滥用模式才是性能瓶颈的根源。重点不在“能不能用”，而在
“怎么用得更稳、更省”。
