go并发核心是正确使用goroutine和channel；需控制goroutine数量、合理设计channel、选型框架要匹配场景，避免竞态与资源泄漏。
Go 处理并发任务，核心不在选框架，而在用对 goroutine 和 channel；框架只是封装层，选错会掩盖问题，而不是解决它。
goroutine 启动数量不是越多越好
常见错误是循环里无节制地起 go f()，尤其在 HTTP handler 或批量任务中，导致 goroutine 泄漏或调度开销爆炸。比如处理 10 万条数据时直接起 10 万个 goroutine，系统可能卡死或 OOM。
- 用固定大小的 worker pool 控制并发度，例如
make(chan func(), 100)配合 5–20 个常驻 goroutine 消费任务 - 对不确定数量的请求（如 HTTP），优先复用
http.Server自带的 goroutine，别在 handler 里再套一层go - 启动前加
runtime.GOMAXPROCS(n)并不总能提升性能，现代 Go 默认已设为 CPU 核心数，手动调高反而增加调度负担
channel 设计要匹配使用场景
用错 channel 类型会导致阻塞、死锁或丢失数据。比如用无缓冲 channel 做异步日志，一卡全卡；用大缓冲 channel 存大量中间结果，内存直接涨上去。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 纯同步通知（如 wait group 替代）：用
make(chan struct{})，零内存开销 - 生产者-消费者解耦：用有缓冲 channel，容量设为预期峰值并发数 × 单任务平均耗时（单位 ms），避免频繁阻塞
- 绝不从多个 goroutine 关闭同一个 channel，只由生产者关；消费者用
for v := range ch安全退出
Gin/Echo/Fiber 的并发行为差异很实际
它们底层都用 net/http，但中间件和路由匹配方式影响并发表现。Gin 默认无 panic 捕获，一个 handler panic 会 kill 整个 goroutine；Echo 默认 recover，Fiber 则用 fasthttp，不依赖标准库 http，连接复用更强但不兼容部分 http.Handler 接口。
- 高吞吐简单 API：选
Fiber，它的ctx.SendString比 Gin 的c.String少一次内存拷贝 - 需要丰富中间件生态（如 JWT、Swagger）：选
Gin，社区成熟，但注意gin.Default()自带的 logger/recovery 有锁竞争，QPS 超 5k 时建议替换为无锁日志 - 平衡性能与标准兼容性：选
Echo，它的echo.New().ServeHTTP可直接嵌入任何 http.Handler 链，调试和网关集成更稳
并发错误最难 debug 的其实是竞态，不是 panic
go run -race 能抓到大部分共享变量读写冲突，但很多问题藏在更隐蔽的地方：比如多个 goroutine 共用一个 sync.Pool 获取的对象未重置字段，或 time.Timer 重复 Reset() 导致 timer 泄漏。
- 所有跨 goroutine 传递的结构体，如果含指针或 map/slice，必须深拷贝或加文档说明“不可复用”
- 避免在 goroutine 里直接用闭包捕获循环变量，写成
go func(v int) { ... }(i)显式传参 - 用
context.WithTimeout统一控制超时，别靠time.After+ select，后者无法取消，goroutine 可能永远挂起
真正卡住系统的，往往不是 goroutine 数量，而是 channel 阻塞没超时、timer 没 Stop、context 没 cancel —— 这些地方没有 panic，却让资源缓慢泄漏，直到某次压测才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
