kratos.New()启动panic的根本原因只有三个：未在main()第一行调用conf.Load()注册配置源、未创建http/grpc.Server实例、未将实例传入Server参数列表。
kratos.New() 启动就 panic，不是代码写错了，是服务协同的初始化顺序没对齐——多服务共存时，配置加载、Server 实例创建、模块注册这三件事必须严格串行，漏一个或错序，整个启动链就断在第一秒。
conf.Load() 必须在 main() 第一行执行
多服务协同场景下（比如召回、排序、过滤三个 Kratos 服务共用一套 config 中心），conf.Load() 不能等日志、flag 或 wire 注入完成后再调。它得是 main() 函数里第一个动作，否则 kratos.New() 内部触发配置读取时发现没有注册任何 config.Provider，直接 panic 报 no config provider registered，不提示文件路径，也不带 stack trace。
实操建议：
- 用
config.NewFile("configs/app.yaml")显式传参，别依赖环境变量拼接；os.Getenv("CONFIG_PATH")得自己塞进config.NewFile()，Kratos 不解析变量占位符 - 检查
c.Load()返回的error：如果configs/app.yaml不存在，c.Load()会返回非 nil error，不检查就继续往下走，后续 panic 更难定位 - 多个服务共用配置源时，确保每个服务的
conf.Load()都独立调用，不要试图“共享”一个 config 实例——Kratos 的 config 是单例但不可跨进程复用
grpc.Server 和 http.Server 必须显式创建并传入 kratos.New()
协同开发中常见错误：一个服务启了 gRPC，另一个只跑 HTTP，结果后者调 service.Register() 时报 rpc error: code = Unavailable。根本原因不是网络不通，是 grpc.Server 根本没创建，或者创建了但没传给 kratos.New()。
实操建议：
- 确认是否调用了
grpc.NewServer()，且返回值非 nil（比如 consul 连不上时consul.New()可能返回 nil + error，只判 error 会漏掉实例） - 必须把
grpcSrv和httpSrv都塞进kratos.New(kratos.Server(httpSrv, grpcSrv))；漏传grpcSrv就等于没启 gRPC 监听 - 监听地址别写
localhost:9000：某些容器或 CI 环境下localhost解析失败，统一用0.0.0.0:9000 - 如果某个服务纯 HTTP 不用 gRPC，就彻底删掉
service.Register()调用——它和 HTTP 路由完全无关，强行调只会因找不到 server 实例而 panic
proto 生成必须用 protoc-gen-go-grpc 而非 protoc-gen-go
协同服务间通过 gRPC 通信，但 A 服务能调通 B 服务的前提是：B 服务的 .proto 文件生成的 Go 代码里，有 RegisterXXXServiceServer 函数。这个函数不是 protoc-gen-go 生成的，必须用 protoc-gen-go-grpc（v2 版本）配合 protoc-gen-go-http 一起生成。
实操建议：
- 单独装
protoc-gen-go只生成*.pb.go，不生成 gRPC Server 注册逻辑，也不生成 HTTP 映射，service.Register()会找不到目标函数 - 验证生成结果：打开生成的
xxx_grpc.pb.go，搜索Register，确认存在形如RegisterMetadataServiceServer的函数 - 多服务共用 proto 仓库时，确保所有服务都用同一套 protoc 插件版本，避免因插件差异导致注册函数签名不一致
多服务协同最易被忽略的点，是每个服务的 main() 启动流程看似独立，实则共享同一套初始化契约——配置加载时机、Server 实例生命周期、proto 生成一致性，三者缺一不可。一旦某个服务偷偷改了 conf.Load() 位置，或换了 protoc 插件版本，整个协同链路就会在启动瞬间静默断裂，错误信息却只字不提真正原因。
