go微服务高并发失效主因是限流熔断等配置错误：rate.limiter须按ip/userid分key隔离、禁用wait避免goroutine堆积、burst需权衡突发与下游承载力，redis限流用滑动窗口zset，就绪探针与连接池预热必须到位。
Go 微服务扛不住高并发，通常不是语言问题，而是限流、熔断、连接池、就绪探针这几处没配对——配错一处，压测时 P99 延迟就跳 300ms，503 暴增。
rate.Limiter 怎么用才不翻车
别全局共享一个 rate.Limiter 实例，也别在 handler 里每次 new 一个。它必须按请求维度隔离，否则健康检查和支付接口共用一个桶，/health 被限流就会触发误下线。
- 按
IP或userID构建 key，用sync.Map缓存*rate.Limiter实例，key 过期需自行清理（比如带 TTL 的 LRU） -
rate.NewLimiter(rate.Limit(10), 20)表示「长期速率 10 QPS，最多允许 20 个突发」，burst 设太小（如 1）会削平所有毛刺，设太大（如 100）可能瞬间打穿下游连接池 - 永远用
limiter.Allow()+ 立即返回429，别用limiter.Wait(ctx)；后者会挂起 goroutine，高并发下堆积等待协程，反而拖垮吞吐
多实例部署时 Redis 限流怎么写 Lua 脚本
单机 rate.Limiter 在 Pod 扩容后完全失效，硬靠本地缓存同步计数是典型幻觉——数据不一致、锁竞争、延迟高，三者必占其一。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 固定窗口用
INCR + EXPIRE最简，但窗口切换时有临界流量尖峰；适合登录尝试限制这类低敏感场景 - 核心链路（如下单、支付）必须用滑动窗口，
ZSET存时间戳 + Lua 脚本原子计算「过去 60 秒请求数」，避免窗口跳变 - Redis 连接池
MaxActive至少设为 20，否则限流中间件自己先connection refused
新 Pod 上线瞬间为啥打爆下游
就绪探针通过、LB 切流、但 Redis 连接池还没填满、gRPC 连接未建立、本地缓存没预热——此时流量进来，大量 connection refused 或超时，不是下游崩了，是你没等稳就上线。
- Kubernetes 中
readinessProbe.initialDelaySeconds至少设 5–10 秒，periodSeconds ≤ 3，确保探测频率够高 - 不要在
init()或main()做耗时初始化；改用sync.Once+ 懒加载，比如redis.Dial成功、grpc.Dial连通、sync.Map预热完成后再返回 200 - 横向扩缩容后，主动调用下游
/health?check=cache类熔断接口探测，失败则暂缓流量接入，别等被动重试失败再降级
goroutine 泛滥的真实代价是什么
“Go 并发强”不等于“每个请求 go 一下就安全”。压测时 runtime.NumGoroutine() 突破 5000，P99 延迟飙升、GC STW 频繁，根本原因是调度器被压垮，不是 CPU 不够。
- HTTP handler 里禁止裸写
go handle(req)；改用带缓冲的 worker pool（如ants），或用semaphore.Weighted控制 I/O 密集型操作并发度 - 数据库连接池必须显式设上限：
sql.DB.SetMaxOpenConns(50)，否则默认 0（无上限），瞬间建连打爆 MySQL 的max_connections - gRPC 客户端要配
grpc.WithDefaultCallOptions(grpc.MaxCallRecvMsgSize(4 * 1024 * 1024))，避免大响应体触发内存暴涨
最常被忽略的点：就绪探针延迟和连接池预热不是可选项，是上线前必须验证的 checklist；而 rate.Limiter 的 burst 参数不是越大越好，它本质是在 GC STW 和网络抖动之间预留的缓冲余量，不是用来兜底突发流量的保险丝。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
