Go kit 是专为异构微服务设计的可插拔工具包，其 transport 层支持 HTTP/gRPC 等协议，endpoint 层抽象请求响应并叠加中间件，middleware 采用装饰器链式调用，log/metrics 分层解耦且需手动注入 trace 上下文，五层架构可独立替换但需严格保持语义一致性。
Go 微服务开发没有“开箱即用”的单一框架，而是靠组合多个专注领域的工具库来构建可观察、可运维的系统。选错组合或忽略层间契约，容易导致 transport 层改了 endpoint 逻辑就崩、metrics 打点漏了 middleware 链路、日志字段对不上 tracing context。
transport 层该选 net/http 还是 gRPC-Go？
不是“哪个更好”，而是“谁在调你、你怎么暴露”。对外 API 通常走 net/http + JSON（兼容性高、调试方便），内部服务间通信优先用 gRPC-Go（性能好、强类型、天然支持 streaming 和 deadline）。Go kit 的 transport 层就是为这种混合场景设计的：同一组 endpoint 可同时注册 HTTP handler 和 gRPC server。
- HTTP 传输注意设置
http.Server.ReadTimeout和WriteTimeout，否则长连接可能拖垮整个服务 - gRPC 默认不带超时，必须在 client 端显式传
context.WithTimeout，否则后端 hang 住会卡死整个调用链 - 如果要用 gRPC over HTTP/2，确保反向代理（如 Nginx）已开启
http2并透传h2c升级头，否则会降级成 HTTP/1.1 导致连接失败
go-kit 的 middleware 链为什么总断在第一个？
因为 Go kit 的 middleware 是函数式装饰器，返回新 endpoint.Endpoint，但常见错误是忘了把上一个 middleware 的输出作为下一个的输入——尤其是日志、熔断、限流混搭时。
- 顺序很重要：一般按
logging → rate limit → circuit breaker → auth → business logic排，否则熔断器可能拦不住打爆 DB 的请求 - 每个 middleware 必须调用
next(ctx, request)并返回其结果，写成next(ctx, request); return nil就会静默丢掉响应 - 自定义 middleware 里别直接 panic，要转成
errors.New或用kit/transport/http.ErrorEncoder统一处理，否则 HTTP 返回 500 而 gRPC 返回UNKNOWN错误码
日志和 metrics 怎么才能对得上 trace ID？
靠手动塞 ctx.Value 容易漏、难维护。Go kit 的 log 和 metrics 包本身不绑定上下文，但要求你在 transport 层初始化 logger/metrics 时，把 trace ID 从 request header（如 X-Request-ID 或 traceparent）提取出来，注入到 context.Context 中，再透传下去。
- HTTP transport：在
http.NewServer的DecodeRequestFunc里解析 header，用context.WithValue塞进 ctx - gRPC transport：实现
grpc.UnaryServerInterceptor，从metadata.FromIncomingContext拿 trace ID - log 库推荐
zap而非logrus，因为zap的With方法返回新 logger，能自然携带 trace ID 字段；logrus的WithField在 goroutine 多层嵌套时容易污染全局 logger
配置管理用 viper 还是硬编码 struct？
用 viper，但别让它自动监听文件变更并热重载——微服务里配置突变可能引发状态不一致（比如熔断阈值从 50% 突然变成 10%，瞬间打挂下游）。
- 只在服务启动时用
viper.ReadInConfig()加载一次，后续全靠 immutable struct 传递 - 敏感配置（如数据库密码）必须从环境变量读，
viper.AutomaticEnv()开启后，DB_PASSWORD会自动映射到viper.GetString("db.password") - 避免用
viper.Unmarshal直接绑 struct，先校验字段是否存在、类型是否合法，再用mapstructure.Decode显式转换，防止空指针 panic
真正难的不是选哪个库，而是让 transport、endpoint、middleware、log、metrics 这五层之间传递的 context、error、metric key、log fields 保持语义一致——这点在 proto 定义和服务骨架生成阶段就要定死，临时补救只会越补越乱。
