结论：别从零设计框架，优先用kitex或gin+grpc组合，再按需叠加限流、熔断、连接池等能力；手写net.listen+conn.read在高并发下极易出现粘包、goroutine泄漏、心跳失效等问题，80%的自研框架卡死在第三天压测。
直接说结论：别从零设计框架，优先用 Kitex 或 Gin + gRPC 组合，再按需叠加限流、熔断、连接池等能力。自己手写网络层（如 net.Listen + conn.Read）在高并发下极易出现粘包、goroutine 泄漏、心跳失效等问题，80% 的“自研高性能框架”卡死在第 3 天压测。
为什么不要自己实现 TCP/HTTP 底层协议解析
常见错误现象包括：连接堆积后 netstat -an | grep :8080 | wc -l 持续上涨但无响应；pprof 显示大量 goroutine 卡在 read 或 write 系统调用；日志里反复出现 broken pipe 或 i/o timeout 却查不到触发点。
根本原因在于：TCP 粘包需手动维护缓冲区+帧头解析；HTTP/1.1 需处理 keep-alive、chunked 编码、header 大小限制；WebSocket 还要处理 ping/pong、close 帧状态机。这些逻辑 Kitex、Gin、Echo 已稳定运行多年，且内置 netpoll（Kitex）或 epoll/kqueue 封装（Gin），QPS 比裸 net 包高 3–5 倍。
- Kitex 默认启用连接复用、自动帧边界识别、元信息透传（如
X-Trace-ID） - Gin 的
gin.Default()已集成recover中间件和gzip支持，无需额外封装 - 所有框架都支持通过
context.WithTimeout控制单请求生命周期，避免 goroutine 悬停
必须显式控制的三个并发原语
框架选型只是起点，真正决定高并发能力的是你如何使用 context、sync.WaitGroup 和 channel。
典型陷阱是：在 HTTP handler 里启动 goroutine 但没传 req.Context()，导致请求取消后 goroutine 仍在后台跑；或用 for range channel 读取异步结果却没关 channel，造成 goroutine 永久阻塞。
-
context必须贯穿整个调用链：DB 查询、Redis 调用、下游 gRPC 都要接收ctx参数并响应ctx.Done() -
sync.WaitGroup的Add必须在 goroutine 启动前调用，否则存在竞态；Done应放在defer里确保执行 - 用
select替代纯channel读写，加入default或ctx.Done()分支，避免无限等待
生产环境绕不开的四个扩展点
无论用哪个框架，上线前必须补上这四块：限流、熔断、连接池、健康检查端点。它们不改变框架结构，但缺一不可。
比如只加了 redis.Dial 却没设 MaxIdle 和 MaxActive，高峰期 Redis 连接数暴涨到 2000+，而服务本身只有 4 核 CPU —— 这不是并发问题，是资源管理缺失。
- 限流：用
golang.org/x/time/rate.Limiter做 per-IP 或 per-token 速率控制，别依赖 Nginx 层做唯一防线 - 熔断：用
sony/gobreaker或自研简单版，失败率 > 50% 且持续 60 秒就跳闸，防止雪崩 - 连接池：DB 用
db.SetMaxOpenConns，Redis 用redigo.Pool或go-redis的Options.PoolSize - 健康检查：暴露
/health接口，检查 DB 连通性、Redis PING、关键依赖服务连通性，K8s readiness probe 必须调用它
最常被忽略的一点：所有中间件（鉴权、日志、限流）必须注册在框架统一入口，而不是每个 handler 里重复写。Kitex 的 server.WithMiddleware、Gin 的 r.Use() 都是为此设计——一旦漏掉某个路由，那个接口就成了高并发下的单点突破口。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
