高并发下需管控goroutine数量、连接复用、context传播与错误扩散。用semaphore限并发，全局复用http.Client和sql.DB，所有 outbound 调用带 context，异步任务需结果归集，禁用盲目 goroutine 启动。
Go Web 服务天然支持高并发，但“能并发”不等于“稳并发”。真正卡住线上服务的，从来不是 goroutine 数量上限，而是连接耗尽、上下文失控、共享资源竞争和慢调用堆积——这些才是高并发下最常崩盘的环节。
怎么限制 goroutine 并发数，而不是任它疯长
直接在 http.HandlerFunc 里写 go process(r) 是最常见也最危险的做法。请求突增时，成千上万个 goroutine 同时启动，内存飙升、调度延迟激增，甚至触发 OOM。
- 用
golang.org/x/sync/semaphore做轻量信号量控制：比如sem := semaphore.NewWeighted(50)，每次请求前sem.Acquire(ctx, 1)，完成后sem.Release(1) - 比 channel 手动实现更可靠：它支持 context 取消，超时自动释放，不会因 panic 或忘记释放导致死锁
- 别设过高值（如 1000+）：实际有效并发受 CPU、I/O、下游能力制约，建议从
2 × runtime.NumCPU()起步，压测后调整 - 避免在 acquire 后做阻塞操作：比如没设 timeout 的
http.Get，会卡住信号量，让后续请求无限等待
HTTP Client 和 DB 连接为什么必须复用
每次新建 http.Client 或 *sql.DB，等于新建一套连接池。默认 MaxIdleConns=100，但若每个 handler 都 new 一个 client，100 个并发请求就可能创建 100 个独立连接池，瞬间打满文件描述符或触发对方限流。
- 全局复用一个
*http.Client，自定义Transport：设置MaxIdleConns: 200、MaxIdleConnsPerHost: 200、IdleConnTimeout: 30 * time.Second -
*sql.DB同样全局复用，并调用db.SetMaxOpenConns(50)和db.SetMaxIdleConns(20)；注意SetMaxOpenConns不是并发数，而是连接句柄上限 - 所有 outbound 调用必须带 context：用
client.Do(req.WithContext(ctx))或db.QueryRowContext(ctx, ...)，否则超时无法传递，goroutine 就悬在那里
为什么不能只靠 “开 goroutine” 解决慢接口
把数据库查询或第三方 API 调用包一层 go func() 然后立刻返回，看似提升了响应速度，实则埋下雪崩隐患：失败不通知、错误被吞、资源不释放、结果无归处。
Websphere教程 中文WORD版
下载
本文档是Websphere教程；WebSphere 是因特网的基础架构软件，也就是我们所说的中间件。它使企业能够开发、部署和集成新一代电子商务应用（如 B2B 的电子交易），并且支持从简单的 Web 发布到企业级事务处理的商务应用。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
立即学习“go语言免费学习笔记（深入）”；
-
异步任务必须有结果归集机制：用
errgroup.Group并发发起多个可并行的下游请求，并统一等待或提前取消 - 非关键路径（如日志上报、埋点）可用 fire-and-forget，但必须包
defer func() { recover() }()，防止 panic 波及主流程 - handler 内绝不阻塞：哪怕只是
time.Sleep(100 * time.Millisecond)，也会占住一个 goroutine，QPS 上不去还浪费栈空间 - 用
pprof验证真实瓶颈：启动时注册net/http/pprof，压测中访问/debug/pprof/goroutine?debug=1查堆积，用go tool pprof抓 CPU 热点，别靠猜
高并发的难点不在“怎么并发”，而在“怎么收住”——收住 goroutine 数量、收住连接生命周期、收住 context 传播、收住错误扩散路径。这些地方稍一松懈，压测数据再好看，上线后第一个流量高峰就教你重新做人。
