go kit 的 service 层必须先定义接口（如 stringservice），再由 struct 实现，否则无法满足 endpoint 和 transport 对接口类型的依赖，导致编译失败、中间件失效及测试困难。
Go Kit 的 service 层必须先定义接口，不能直接写 struct 实现
Go Kit 不是框架，它依赖显式的接口契约来组织业务逻辑。如果你跳过 IUserService 这类接口直接写 UserService struct 并暴露方法，后续加中间件、替换实现、做单元测试都会卡住。
常见错误现象：endpoint 无法接收具体类型，MakeUppercaseEndpoint 函数编译失败，提示“cannot use s (type *stringService) as type StringService”——本质是缺少接口约束。
- 必须先声明接口，例如：
type StringService interface { Uppercase(string) (string, error); Count(string) int } - struct 实现该接口时，方法签名要完全一致（包括参数名、返回值顺序）
- 所有 endpoint 构造函数和 transport 绑定都应基于接口类型，而非具体 struct
transport/http.NewServer 的 decode/encode 函数必须处理 error 返回
很多初学者复制示例时忽略 decode 函数的 error 处理，导致请求体解析失败后服务 panic 或静默丢弃请求，日志里只看到 http: panic serving，但没线索。
使用场景：JSON 请求体字段缺失、类型错（如传字符串给 int 字段）、结构体 tag 写错（json:"uid" 拼成 json:"uid_"）都会触发 decode 错误。
-
decodeLoremRequest必须返回(request interface{}, err error)，且 err != nil 时不能返回部分填充的 request - transport 层默认不捕获 decode error，需在 handler 外层加 middleware 或自定义 server 包装
- 推荐在 decode 后立刻 log 错误，例如：
logger.Log("err", err, "method", "decodeLoremRequest")
endpoint 中间件链顺序直接影响限流和日志行为
Go Kit 的中间件是函数包装链，顺序决定执行流。把 ratelimit 放在 logging 后面，会导致每次请求都记日志，哪怕被限流拦截了；反过来，限流就看不到被拒绝的请求上下文。
性能影响：log middleware 在最外层会记录所有进来的请求（含 429），放在断路器后面则只记录实际转发的请求，日志量差一个数量级。
- 典型安全顺序：
auth → circuitbreaker → ratelimit → logging → endpoint - 不要把
circuitbreaker放在ratelimit后面——限流失效时断路器可能永远收不到足够失败信号 - 所有中间件函数签名必须统一为
func(Endpoint) Endpoint，否则链式调用中断
Kubernetes 部署时 containerPort 和 service port 必须对齐，否则流量不通
本地 go run main.go 能跑通，Docker 容器里也能 curl 通，但一上 Kubernetes 就 503，大概率是端口映射断在了 Service 层。
容易踩的坑：deployment.yaml 里写了 containerPort: 8080，但 service.yaml 的 port 写成 80 或 3000，K8s Service 不会自动转发；或者 Go 服务实际监听的是 9000，但 Dockerfile 没改 EXPOSE，K8s 健康检查探针失败。
- 确认三处端口一致：Go 代码中
http.ListenAndServe(":8080", ...)、Dockerfile 的EXPOSE 8080、deployment 的containerPort: 8080、service 的port: 8080 - K8s Service 的
targetPort可以省略（默认等于port），但显式写出更安全 - 用
kubectl port-forward直连 Pod 验证端口是否真通，绕过 Service 层排查
