go框架不定义并发模型，依赖goroutine和channel，开发者需手动管理其生命周期；main退出会强制终止所有非主goroutine，必须用waitgroup或context实现优雅退出；goroutine泄露源于永久阻塞，可用pprof定位；应通过信号量或worker pool控制并发数量。
Go 框架本身不定义并发模型，它完全依赖语言原生的 goroutine 和 channel；所谓“框架中的并发”，其实是开发者在框架生命周期内如何安全、可控地调度和管理 goroutine —— 这不是框架帮你做，而是你必须亲手做对的事。
main 函数退出时 goroutine 会被强制终止
这是最常被忽略的前提：Go 程序结束 = 所有非主 goroutine 立刻被杀，不管它们是否正在写日志、上传文件或等待数据库响应。没有“优雅退出”这回事，除非你主动干预。
-
time.Sleep是临时调试手段，绝不能用于生产环境——它无法感知任务是否真正完成 - 必须用
sync.WaitGroup或context.Context显式等待，且WaitGroup.Add()调用必须在go启动前完成（否则可能竞态） - HTTP 服务器（如
net/http）启动后会阻塞main，但中间件、钩子函数里启的goroutine仍需自行管理生命周期
goroutine 泄露的典型场景与检测方式
泄露 ≠ 内存不释放，而是 goroutine 持续阻塞在 channel 接收、time.Sleep 或网络调用上，且再无机会被唤醒。这类 goroutine 会永久占用栈内存并计入 runtime.NumGoroutine()。
- 向已关闭的
chan发送数据 → panic，但若只接收，会永远阻塞在 - 使用无缓冲
chan但只发不收，或只收不发 → 双方永久阻塞 - HTTP handler 中启 goroutine 处理耗时任务，却未传入带超时的
context.Context→ 请求结束后 goroutine 还卡在http.Get或db.Query - 用
pprof查看/debug/pprof/goroutine?debug=2，能直接看到所有 goroutine 当前堆栈，定位卡死点
控制并发数量：别硬扛，要节制
框架不会替你限流。启动成百上千个 goroutine 处理请求，看似“高并发”，实则可能压垮数据库连接池、触发 GC 频繁暂停，甚至因线程数超限导致系统调用失败。
- 用带缓冲的
sem := make(chan struct{}, N)做信号量，比sync.Mutex更轻量、更符合 Go 的通信习惯 - Worker Pool 模式中，任务 channel 必须有缓冲（如
make(chan Job, 100)），否则生产者可能被阻塞，拖慢整个流程 -
runtime.GOMAXPROCS通常无需修改，默认值是 CPU 核心数；强行设为 1 不会“串行化 goroutine”，只是限制 P 的数量，反而可能降低 I/O 并发吞吐
真正难的不是启动 goroutine，而是知道它什么时候该停、怎么停、停之前有没有清理资源——这些细节不会出现在框架文档里，得靠你在每个 go 语句前后多想半秒。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
