应直接用net/http而非gin构建api网关，因其核心诉求是低延迟、高吞吐、强可控；gin中间件链和路由树在百万级qps下引入8–12%额外cpu开销，而net/http可精简至最简路径，如用servemux+前缀匹配、手动设header、避免自动解码等。
为什么不用 Gin 而直接用 net/http 做 API 网关
因为网关的核心诉求是低延迟、高吞吐、强可控，Gin 的中间件链和反射路由在百万级 QPS 场景下会引入可观的额外开销（实测约 8–12% CPU 消耗），而 net/http 的 ServeMux 或自定义 Handler 能压到最简路径。你不是在写业务服务，是在建流量入口——每纳秒都算数。
实操建议：
- 用
http.NewServeMux()替代gin.Default()，避免默认日志、恢复 panic 等非必要中间件 - 路由匹配改用前缀判断或
strings.HasPrefix(r.URL.Path, "/api/v1/")，比正则/树形匹配快 3 倍以上 - 请求体读取统一用
r.Body+io.LimitReader控制最大长度，防 OOM，别依赖框架自动解码 - 响应头手动设置
w.Header().Set("Content-Type", "application/json; charset=utf-8")，跳过 Gin 的 MIME 推断逻辑
gRPC 服务注册时 Consul Check 失败的常见原因
Consul 服务注册后显示 critical 状态，90% 是健康检查端点不可达或返回非 200。它不看你服务是否启动了，只认 HTTP status code 和响应时间。
实操建议：
-
Check.HTTP必须是完整 URL（如"http://localhost:8080/health"），不能只写路径；且该地址必须能被 Consul agent 所在机器 curl 通 -
Check.Timeout建议设为"500ms"，太长会导致 deregister 延迟；DeregisterCriticalServiceAfter设为"30s"，避免瞬时抖动误剔除 - 健康检查 Handler 必须返回
http.StatusOK，且 body 为空或极简（如w.Write([]byte("ok"))），任何 JSON 序列化或 DB 查询都可能超时 - 若服务跑在 Docker 中，
Address别填容器名（如"user-service"），Consul agent 通常不在同一网络；改用宿主机 IP 或"127.0.0.1"+ host network 模式
goroutine 泄漏比内存泄漏更难发现，但更容易致命
一个没回收的 goroutine 占用至少 2KB 栈空间，且持续持有闭包变量引用。线上服务跑一周后 RSS 内存涨 3GB，查下来是日志上传协程没加 context.WithTimeout，上游服务已下线，它还在死等 channel。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
- 所有
go f()调用前，先问：它有没有明确退出条件？有没有 context 控制？有没有 channel 关闭信号？ - 用
runtime.NumGoroutine()+ Prometheus 暴露指标，设置告警阈值（如 > 5000 持续 2 分钟） - 避免在循环里无节制启 goroutine：
for _, item := range items { go process(item) }→ 改用带缓冲的 worker pool（如sem := make(chan struct{}, 10)） - 调试时用
curl http://localhost:6060/debug/pprof/goroutine?debug=2查看堆栈，重点关注select {}、chan receive、time.Sleep长时间阻塞的 goroutine
GORM 连接池配置不当导致数据库打满
默认 MaxOpenConns=0（无限），但 MySQL 默认 max_connections=151。10 个微服务实例各开 50 连接，瞬间就把 DB 打挂，错误日志里全是 "Error 1040: Too many connections"。
实操建议：
- 显式设置
db.SetMaxOpenConns(20)和db.SetMaxIdleConns(10)，数值按单实例 QPS × 平均 SQL 耗时（秒）× 1.5 估算 - 用
db.Stats()定期打印OpenConnections和WaitCount，WaitCount > 0说明连接不够用 - 避免在 HTTP handler 里直接调
gorm.Open，它会新建连接池；所有 DB 实例应在main()初始化并复用 - 对高频只读查询（如配置项），优先走 Redis 缓存，别让 GORM 每次都穿透到 DB
微服务不是把单体拆成多个二进制文件就完事了；真正的难点藏在连接生命周期、上下文传播、资源配额这些“看不见的线”里。一次 goroutine 泄漏，可能比十次代码逻辑错误更早拖垮整个集群。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
