不能直接用于生产环境的微服务，因其默认 logger 日志非结构化、recovery 不上报错误、缺乏 trace-id 注入点，导致链路追踪与错误归因困难；须改用 gin.new() 并集成带 trace 支持的自定义中间件。
gin.Default() 在微服务里能不能直接用
不能直接用于生产环境的微服务。它自带 Logger 和 Recovery 中间件，开发调试方便，但日志格式不统一、panic 恢复后无法上报、缺少 trace-id 注入点——这会让服务链路追踪和错误归因变得困难。
- 微服务要求每个请求携带唯一
trace_id，gin.Default()不提供注入入口，必须手动在自定义中间件里生成并写入c.Request.Context() -
Recovery只打印 panic 堆栈到 stdout，不触发告警或上报到 Sentry / Prometheus，线上出问题时响应滞后 - 日志输出是纯文本，没结构化字段（如 service_name、span_id、http_status），ELK 或 Loki 无法高效过滤
- 正确做法：用
gin.New()初始化引擎，再按需注册带 trace 支持的中间件，例如：router.Use(middleware.TraceID(), middleware.RecoveryWithReporter(sentry.Reporter))
如何让 Gin 路由支持服务发现与健康检查
Gin 本身不内置服务发现，但可以通过标准 HTTP 端点 + 外部注册机制对接 Consul / Nacos / Etcd。关键不是“怎么注册”，而是“注册什么”和“怎么被发现”。
- 健康检查接口必须是无状态、低开销的，推荐用
GET /healthz，返回200 OK+ 简单 JSON（如{"status": "ok", "timestamp": 1723307656}），不要查 DB 或调下游 - 服务元数据（如 version、region、weight）应通过请求头或 query 参数传递，例如
GET /register?ip=10.0.1.12&port=8080&tags=v2,canary，由注册中间件解析并上报 - 避免在
router.GET("/healthz", ...)里调用c.Request.Host做判断——K8s Service 或 Istio Sidecar 可能改写 Host，应优先读取X-Forwarded-For或X-Real-IP - 注册逻辑不要耦合在路由 handler 里，建议抽成独立 goroutine + 定时心跳，防止注册失败阻塞主请求流
微服务间 JSON 通信时 c.ShouldBindJSON 的坑
c.ShouldBindJSON() 看似简单，但在跨服务调用场景下极易因结构体标签或上下文超时导致静默失败或 panic。
- 必须显式设置 struct tag，尤其是嵌套结构体：如果上游发来
{"user_info":{"name":"a","id":1}}，接收端字段得写UserInfo UserInfo `json:"user_info"`，漏掉 tag 就解不出 - 不要依赖默认超时——HTTP client 超时（如 5s）和 Gin 绑定超时（默认无限）不一致，容易卡住协程；应在 handler 开头加
ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second); defer cancel() - 绑定失败时
c.ShouldBindJSON()返回 error，但不会自动中断执行，常见错误是忘记if err != nil { c.AbortWithError(http.StatusBadRequest, err); return } - 对空数组或 null 字段敏感：前端传
"tags": null，而结构体字段是[]string，会触发 unmarshal error；建议用指针类型*[]string或预设默认值
Gin 中间件怎么透传 trace_id 并关联日志
核心不是“加中间件”，而是确保 trace_id 从入站请求头（如 X-Trace-ID）提取后，贯穿整个请求生命周期，并被所有日志语句捕获。
- 提取逻辑必须放在第一个中间件，且用
c.Request = c.Request.WithContext(context.WithValue(...))注入，不能只存到c.Set("trace_id", ...)—— 后续调用的第三方库（如 sqlx、redis）拿不到 - 日志中间件里别用
log.Printf，要用结构化 logger（如 zap）并把trace_id作为 field 写入，例如：logger.Info("request start", zap.String("trace_id", traceID)) - 注意 Goroutine 泄漏：如果在中间件里启了异步 goroutine（如上报 metrics），必须确保它能随请求 context cancel 而退出，否则 trace_id 会错乱
- 测试时容易忽略的点：单元测试里
gin.CreateTestContext不带真实 request，需手动构造httptest.NewRequest并设置 header，否则 trace_id 为空
