Kratos不是开箱即用框架，kratos new生成项目缺服务注册、配置兜底和可观测性接入；middleware链必须按recovery→logging→tracing→ratelimit顺序；proto需http.proto与error.proto对齐错误码；Wire注入须避免循环依赖和资源泄漏。
Kratos 不是“开箱即用就能上生产”的框架，它提供的是骨架和规范，真正的生产级能力取决于你怎么填内容、怎么设边界、怎么处理失败。
kratos new 生成的项目为什么不能直接部署？
刚执行 kratos new order-service 得到的项目，只具备最小可运行结构：HTTP/gRPC 服务能启动、健康检查接口返回 200、日志打出来。但它缺三样东西：
- 没有真实的服务注册逻辑（
consul或nacos客户端未初始化） - 没有配置加载兜底机制（
conf/config.yaml里写死的地址在 K8s 环境下会失效） - 没有可观测性接入点（
tracing.Server()中间件启用了，但没配 Jaeger/OTLP endpoint）
这些不是 bug，而是 Kratos 的设计选择：它把“环境适配”这件事交还给开发者，避免强耦合某一种基础设施。
middleware 链里哪些中间件必须加？顺序为什么重要？
一个典型 HTTP server 的中间件链应至少包含 recovery、logging.Server、tracing.Server 和 ratelimit.Server，但顺序不能乱：
-
recovery必须最外层——它捕获 panic，防止整个请求链崩掉 -
logging.Server要在tracing.Server之后——否则 span ID 拿不到，日志里 trace_id 是空的 -
ratelimit.Server建议放在logging之前——限流拒绝的请求不该进业务日志，否则日志量爆炸
错误示例：http.Middleware(logging.Server(), tracing.Server()) → 日志里全是 trace_id= 空值。
proto 文件里 http.proto 和 error.proto 怎么协同工作？
Kratos 的双协议支持依赖 http.proto 描述路由，error.proto 定义错误码映射，两者必须对齐：
-
http.proto中每个get/post方法需标注(google.api.http)，且body字段要与 service 方法签名一致 -
error.proto中定义的code（如INVALID_ARGUMENT = 400）必须和 HTTP 状态码匹配，否则errors.New返回的 error 不会被自动转成对应 status code - 若新增一个自定义错误
ORDER_NOT_FOUND = 404，必须同时在error.proto声明，并在 handler 中显式调用errors.New(404, "ORDER_NOT_FOUND", "order not exist")
漏掉任一环，API 就会返回 500 而不是预期的 404，前端无法做精准错误处理。
Wire 注入时如何避免循环依赖和资源泄漏？
wire.go 里声明依赖时，最容易踩的两个坑是：
- 把
*grpc.ClientConn直接注入 service 层——它应该只出现在 client 包里，service 层只依赖 interface（如UserClient），否则测试时无法 mock - 在
InitApp函数里 new 了数据库连接但没传给 cleanup 函数——导致app.Stop()时连接没关闭，K8s 下 pod 重启前出现连接数爆满 - 多个 service 共享同一个
redis.Client实例没问题，但不要在每个 service 的NewXXXService里都redis.NewClient()—— 连接池会重复创建
Wire 不是魔法，它只是把 new 和 inject 的代码自动化了；谁负责释放资源，谁就要在 app.Run() 之外显式管理生命周期。
真正卡住上线的，从来不是 Kratos 的某个 API 不好用，而是 config 加载时机不对、中间件顺序错位、proto 错误码没对齐、或者 Wire 里漏写了 cleanup 步骤——这些地方没报错，但会在压测或灰度时突然暴露。
