全局变量和包级sync.Map是无状态设计的第一道雷，因其会隐式存储请求相关数据（如session、计数器），导致多实例状态不一致、重启后数据丢失或并发panic；正确做法是仅将请求级数据绑定req.Context()，包级变量限用于常量、配置结构体或真正无状态资源（如sql.DB）。
为什么全局变量和包级 sync.Map 是无状态设计的第一道雷
Go 微服务一旦在 var 声明处或 init() 函数里存请求相关数据（比如用户 session 缓存、计数器、临时 map），就立刻变成有状态服务。K8s 扩容后，新实例无法继承旧实例的内存状态，请求路由到不同 Pod 就可能返回不一致结果，甚至 panic。
常见错误现象包括：
- 用
sync.Map存用户 token 到内存，重启后登录态丢失但部分请求仍能通过 - HTTP 中间件往包级
map[string]interface{}写 traceID，导致并发写 panic - 数据库连接池以外的 client（如带本地 LRU 的 Redis client）被声明为全局变量，造成连接复用错乱
正确做法是：
- 所有请求级数据必须绑定在
req.Context()或 handler 入参中传递 - 包级变量只允许用于常量、配置结构体（如
Config{Port: 8080}）、或真正无状态的共享资源（如sql.DB连接池） - 中间件函数签名必须是纯函数：
func(http.Handler) http.Handler，不读写任何外部变量
健康检查接口 /healthz 怎么写才不会引发级联驱逐
K8s 的 LivenessProbe 如果调用下游服务（比如查 MySQL 主从延迟、调另一个微服务的 /healthz），就会把局部抖动放大成全链路雪崩。A 服务因 B 服务超时被 K8s 杀掉重启，B 的压力反而更大。
立即学习“go语言免费学习笔记（深入）”；
真正的无状态健康检查只验证当前实例“能不能活”，不是“整个系统好不好”。必须满足：
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
-
/healthz返回 200 当且仅当：http.Server正常监听、db.Ping()成功、redis.Ping()成功（如果用了）、磁盘剩余空间 >5% - 所有依赖检查加
context.WithTimeout(ctx, 2*time.Second)，超时直接返回 503，不重试 - 禁止在
/healthz里查其他服务、不做业务逻辑判断（比如“用户表有没有数据”） -
/readyz可额外检查：配置是否已加载、缓存 key 是否预热完成，但同样不能跨服务
配置热重载为什么破坏无状态性
很多团队用 fsnotify 监听配置文件变更，或用 viper.WatchConfig() 实现运行时 reload。这看似灵活，实则让同一时刻不同 goroutine 看到不同配置值——刚收到新请求的 goroutine 用新超时值，正在处理的请求还在用旧重试策略，熔断阈值、JWT 过期时间等关键参数瞬间不一致。
无状态服务的配置管理原则是：
- 启动时一次性读取：
os.Getenv("REDIS_URL")、flag.String("env", "", "env name, required") - 缺失关键配置直接
panic，不 fallback 默认值（避免测试环境跑通、生产环境出事） - K8s 场景下，用
ConfigMap或Secret挂载为只读文件，配合滚动更新 + 进程重启来切换配置 - 绝对不要监听
os.Signal做 reload —— graceful shutdown 已经由http.Server.Shutdown()覆盖
日志和指标怎么打才不丢数据也不串号
每个 Pod 实例独立打日志到 stdout 是安全的，但只要写本地文件（log.Printf("log.txt", ...)）或自建未对接 remote write 的 Prometheus registry，横向扩容后日志就分散在各节点、指标根本没法聚合查询。
关键点在于：
- 日志必须输出到
os.Stdout，用req.Context()携带traceID，而不是靠全局 logger 实例存字段 - 指标注册必须用默认 registry：
prometheus.DefaultRegisterer，而非prometheus.NewRegistry()自建 - 打点函数如
http_requests_total.Inc()必须在 handler 内部调用，不能在 middleware 外层或全局初始化里埋点 - 所有日志行必须包含
traceID和method/path字段，否则在 Loki/Promtail 里无法按请求串联
最容易被忽略的是 traceID 的生命周期 —— 它必须从 req.Context() 一路透传进 DB 查询、Redis 调用、下游 gRPC 请求，否则日志和指标在分布式追踪里就是断的。
