最常卡住的地方是并发失控、资源耗尽、上下文丢失、可观测性缺失四类问题：goroutine泄漏因channel未关闭或select缺default导致堆积；HTTP超时未设引发连接耗尽；context未贯穿全链路致取消失效；日志与指标缺乏结构化使故障难定位。
Go语言构建高并发微服务后端架构，最常卡住的地方不是“写不出并发代码”，而是**并发失控、资源耗尽、上下文丢失、可观测性缺失**这四类问题。它们往往在压测或上线后集中爆发，且难以复现。
goroutine 泄漏导致内存持续增长
看似简单的 go func() 调用，在 channel 未关闭、select 缺少 default 或阻塞读写未设超时的场景下，极易形成 goroutine 堆积。比如一个 HTTP handler 中启动 goroutine 处理异步日志，但没加 context 控制，请求中断后 goroutine 仍挂起等待 channel 写入。
- 用
pprof/goroutine快速定位：访问/debug/pprof/goroutine?debug=2查看堆栈，重点关注阻塞在chan send或chan receive的 goroutine - 所有 channel 操作必须配对：有
close()就要有range或带超时的select；无缓冲 channel 一定要确保两端都就绪 - 避免在 handler 中裸启 goroutine，优先用
context.WithTimeout包裹并传递 cancel 函数
HTTP 服务未设超时引发连接堆积
net/http 默认不设超时，一旦下游 gRPC 或 DB 响应慢，连接会卡在 http.Transport 连接池里，最终耗尽文件描述符（too many open files）。
- 必须显式配置
http.Server的ReadTimeout、WriteTimeout、IdleTimeout -
http.Transport需设MaxIdleConns、MaxIdleConnsPerHost和IdleConnTimeout，否则连接池无限扩张 - 对外调用统一走
http.Client实例（非默认 client），且每个实例绑定独立 transport，避免全局污染
context 未贯穿全链路导致超时/取消失效
从 HTTP 入口到数据库查询、gRPC 调用、缓存操作，只要任意一环没传 ctx 或用了 context.Background()，上游发起的 cancel 就会断掉——超时控制形同虚设。
立即学习“go语言免费学习笔记（深入）”；
- 所有可取消操作（
db.QueryContext、redis.Client.Get(ctx, key)、grpc.ClientConn.Invoke(ctx, ...)）必须接收context.Context参数 - 中间件中用
c.Request.Context()提取，而非新建context.Background() - 跨 goroutine 传递 context 时，禁止用
context.WithCancel(context.Background())这类“孤儿 context”，应基于入参 ctx 衍生
日志与指标缺乏结构化，故障难定位
用 fmt.Println 或简单字符串拼接日志，在高并发下既慢又难过滤；没有埋点指标，连“哪个接口慢”“哪台实例异常”都得靠猜。
- 日志必须用结构化库（如
zap或slog），关键字段（req_id、user_id、duration_ms）作为key:value打出，而非拼接字符串 - HTTP handler 开头生成唯一
req_id，通过context.WithValue注入，并在所有子 goroutine 日志中透传 - 核心路径（DB 查询、RPC 调用）必须打
prometheus指标：计数器（http_requests_total）、直方图（http_request_duration_seconds）、Gauge（goroutines_total）
真正棘手的不是语法或框架选型，而是这些细节在单机开发时毫无感知，一上生产流量就暴露——尤其 context 传递断裂和 goroutine 泄漏，往往要靠 pprof 抓现场，而不是靠代码 review 发现。
