Kratos服务启动时NPE主因是Wire注入失效或生命周期错配，常见于Provider返回nil未panic、Proto字段变更后wire未同步、Service方法值接收器导致注入丢失、测试中手动new绕过Wire。
Kratos 服务一启动就报 NullPointerException，八成不是业务逻辑问题，而是 Wire 依赖注入没生效或对象生命周期错配。 这类空指针往往发生在 service、repository 或 dao 层字段为 null，但日志里不显式提示“注入失败”，只在首次调用时炸开——因为 Kratos 默认不校验注入结果，直到你真正去 call 那个 null 对象的方法。
Wire 初始化失败：provider 返回 null 却没被拦截
Kratos 的依赖注入靠 wire 在编译期生成 InitApp()，如果某个 Provider 函数返回了 nil（比如数据库连接失败、配置缺失导致 sql.Open() 返回 (nil, err)），而你又没在 provider 里加 if err != nil { panic(err) }，Wire 就会默默把 nil 赋给对应字段。运行时一调用就 NPE。
- 检查所有
Provider函数，确保返回error时显式 panic 或 log.Fatal，不能只返回nil+err - 重点盯
NewData()、NewDAO()、NewRepo()这类初始化函数，尤其是涉及sql.Open、redis.NewClient、grpc.Dial的地方 - 在
main.go的InitApp()调用前后加日志，确认app和各模块实例是否非nil
Proto 生成代码未更新：结构体字段名变更后 wire 注入失效
当你改了 .proto 文件（比如重命名一个 message 字段、删掉一个 service method），再运行 go generate ./，protoc 会重新生成 pb.go，但 wire.go 不会自动同步——它仍按旧字段名去注入，而新生成的 struct 字段已不存在或类型不匹配，导致对应字段保持零值（nil）。
- 每次修改
.proto后，必须手动确认wire.go中相关Bind或Struct声明是否与新pb.go中的 struct 字段一致 - 特别注意嵌套结构体，比如
user.User改成user.UserInfo，wire里若还写user.User就会注入失败 - 用
go vet -tags=wire可提前发现部分绑定不匹配问题，但不能覆盖全部场景
Service 方法接收器为值类型：方法内修改字段不生效且易引发 NPE
Kratos 的 Service 通常定义为结构体，如果它的方法接收器用了值类型（func (s Service) Method()），那方法内对 s.field 的任何赋值都不会反映到原始实例上。若该字段本应由 Wire 注入，但你在值接收器方法里又尝试二次赋值（比如 s.dao = dao），实际只是改了副本，原始 Service 实例的 dao 仍是 nil。
- 所有 Service 方法接收器必须用指针类型：
func (s *Service) Method() - 检查
internal/service/xxx_service.go中所有方法签名，尤其注意自动生成的模板代码是否被误改 - 若 Service 本身是通过
wire.Struct(new(Service), ...)注入的，它本身就是指针，值接收器会切断注入链路
测试环境误用 new() 创建 Service：绕过 Wire 容器管理
写单元测试时，有人习惯直接 s := new(Service) 或 s := &Service{}，然后手动 mock 字段。这完全跳过了 Wire 的初始化流程，所有依赖字段都是零值。一旦测试中调用真实方法（比如没打桩的 s.dao.Get()），立刻 NPE。
- 测试中应统一使用
wire.Build构建完整依赖树，或至少用wire.InterfaceValue注入 mock 实例 - 避免在 test 文件里出现
new(XXX)、&XXX{}、XXX{}这类手动构造 - 用
testify/mock或gomock时，确保 mock 实例是通过 Wire 注入进 Service 的，而不是塞进字段后手动调用
最常被忽略的是：Kratos 的 NPE 往往不是单点问题，而是 Wire 初始化链断裂 + proto 生成滞后 + 接收器类型错误三者叠加。排查时别只盯着报错行，先看 InitApp() 是否完整执行、go generate 是否真跑过、Service{} 是不是被谁偷偷 new 了。这些地方一错，后面所有业务逻辑都建立在 nil 地基上。
