微服务需用net/http、chi、gobreaker、zerolog和prometheus/client_golang精确组合，而非Gin/Echo；因后者仅为Web框架，缺乏服务发现、熔断、trace透传等能力，且gin.Context无法跨协议复用，隐式中间件导致测试与替换困难，chi+stdlib则轻量可控、显式建模边界与契约。
微服务不是靠“选一个框架”就能跑起来的，而是靠对几个关键库的精确组合和边界控制——标准库 net/http、context、sync 是底座，chi 替代 Gin/Echo 做路由，gobreaker 控制熔断，zerolog 和 prometheus/client_golang 负责可观测性。缺一不可，但也不能多装。
为什么不用 Gin/Echo 做微服务主干？
它们是 Web 框架，不是微服务框架。强行用 gin.Default() 启动服务，会隐式注入 recovery、logger 中间件，导致：
-
gin.Context无法透传到 gRPC handler 或消息回调中，换协议时要重写全部中间件逻辑 - 超时控制只能靠
c.Timeout，但这个值不参与context.WithTimeout传播，下游 HTTP 客户端或 DB 查询仍可能卡死 - 服务注册、健康检查、指标暴露都得自己 patch，容易漏掉
/healthz或/metrics端点
chi + stdlib 是最轻量可控的组合
chi 只做路由，返回标准 http.Handler，所有中间件必须显式构造并基于 context.Context 传递。典型骨架如下：
func RegisterHandlers(r *chi.Mux) {
r.Get("/healthz", healthHandler)
r.Post("/order", withTimeout(5*time.Second, createOrderHandler))
r.Put("/user/{id}", withAuth(withTimeout(3*time.Second, updateUserHandler)))
}
关键点：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 每个 handler 接收
*http.Request，而非框架私有 context，方便单元测试和跨协议复用 -
withTimeout必须调用r = r.WithContext(context.WithTimeout(r.Context(), dur))，否则下游http.Client.Do或db.QueryRowContext不生效 - 路由注册与主入口解耦，不同服务（
user、order）各自定义RegisterHandlers，避免全局chi.NewMux()污染
HTTP 客户端必须封装，不能裸用 http.DefaultClient
微服务间调用失败率高，裸 client 会导致连接泄漏、无超时、无重试。正确做法：
- 自定义
http.Client，设置Timeout（总超时）、Transport的IdleConnTimeout和MaxIdleConnsPerHost - 所有请求必须带
context.WithTimeout(ctx, 2*time.Second)，且该 ctx 从上游 handler 传入，不新建 - 仅对幂等方法（如
GET）做最多 2 次指数退避重试；POST/PUT不重试，由业务层决定补偿逻辑 - 错误判断用
errors.Is(err, context.DeadlineExceeded)，而不是字符串匹配"timeout"
可观测性和弹性能力不能靠框架自动注入
日志、指标、熔断这些必须显式集成，且与路由、客户端解耦：
- 日志用
zerolog，每条 log 都带request_id和service_name字段，不依赖中间件“全局注入” - 指标暴露走
prometheus/client_golang的http.HandlerFunc，注册到 chi 路由，不绑定任何框架生命周期 - 熔断器用
gobreaker，每个下游服务（如 user-api、payment-svc）配独立实例，状态不共享 -
trace ID必须从req.Header.Get("X-Request-ID")提取并塞进 context，再透传给下游，不能靠中间件自动生
真正难的不是写代码，是守住每一处 context 传递、每一次 close 调用、每一个超时配置的归属权——它们分散在 handler、client、db 层，没人替你兜底。
