Kratos连接暴增主因是下游组件连接未复用或泄漏，非Kratos自身问题；需分层排查MySQL、HTTP服务端及gRPC客户端连接，重点检查rows.Close()、tx.Commit/Rollback、ClientConn复用等泄漏点。
连接数暴增通常不是 Kratos 本身“开太多连接”，而是数据库、gRPC 客户端或 HTTP 客户端未复用连接，或连接泄漏导致的。
查清连接来源：先定位是哪层的连接在涨
连接暴增必须先分层排查，Kratos 自身不管理连接池，它只是胶水。常见三类连接需分别确认：
-
netstat -anp | grep :3306 | wc -l（MySQL）或ss -tan state established | grep :3306 | wc -l—— 看 DB 连接是否异常增长 -
lsof -i :8000 | grep ESTABLISHED | wc -l（假设 Kratos HTTP 服务监听 8000）—— 看服务端接受的 HTTP 连接数是否持续不降 - 如果调用了其他 gRPC 服务，检查客户端侧：
grpc.WithTransportCredentials(insecure.NewCredentials())是否漏配了grpc.WithBlock()或连接池参数，导致每次请求都新建连接
数据库连接泄漏：60% 的 Kratos 连接问题出在这
Kratos 不绑定 ORM，但社区常用 database/sql、sqlx 或 gorm。泄漏最常见于：
- 忘记调用
rows.Close()：用db.QueryContext()后没 deferrows.Close()，连接会一直占着直到 GC（不可靠） - 事务未提交/回滚：显式
tx, err := db.BeginTx(ctx, nil)后，没执行tx.Commit()或tx.Rollback()，底层连接不会归还到池中 -
db.SetMaxOpenConns(n)设得太小（如 5），高并发下排队等待，看起来像连接卡住；设得太大（如 1000）又可能压垮 DB - 没传
context到查询里：db.QueryRow("...")是阻塞的，超时后连接仍占用；应统一用db.QueryRowContext(ctx, "...")并设置ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
HTTP/gRPC 客户端连接未复用
Kratos 的 http.Client 或 grpc.ClientConn 必须全局复用，不能每次请求 new 一个：
- HTTP 客户端：确保用的是单例
http.DefaultClient或自定义的带连接池的 client，且设置了Transport.MaxIdleConns和Transport.MaxIdleConnsPerHost（默认 2，太小！建议至少 100） - gRPC 客户端：必须复用
*grpc.ClientConn，不能每次grpc.Dial()；若用 Kratos 的client.NewClient()，检查是否传入了client.WithMiddleware(...)导致内部重试逻辑反复建连 - Kratos 的
transport/http.NewClient()默认使用http.DefaultClient，但如果你手动构造了http.Client却没配Transport，就会退化成无连接池的短连接模式
连接数监控与快速验证点
别等报警才查，上线前就该埋点：
- DB 层：定期查
SHOW STATUS LIKE 'Threads_connected';，对比max_connections - Go 运行时：暴露
/debug/pprof/heap和/debug/pprof/goroutine?debug=2，看是否有大量net.(*conn).readgoroutine 僵在select上 - Kratos 日志加
log.With().Str("component", "transport").Msg("http server started")级别，确认是否重复启动了多个 HTTP Server 实例（比如kratos.New()被调用多次） - 用
go tool pprof http://localhost:8000/debug/pprof/heap查 heap 中是否有大量net.Conn或database/sql.conn实例
真正难定位的，往往是“连接没被释放”而非“连接建太多”。重点盯住 defer rows.Close()、tx.Rollback()、client.Close() 这三处，它们漏掉任何一个，连接数都会缓慢爬升，几天后突然崩掉。
