kratos.New()启动panic的三大主因是：未在main第一行调用conf.Load()注册配置源、未创建或未传入http/grpc.Server实例、中间件构造函数访问nil依赖；必须显式校验并提前初始化。
启动报错基本不用猜，90% 是配置加载、依赖注入或中间件构造阶段 panic，直接看 panic traceback 第一行就能定位到具体函数。
conf.Load() 没在 main 第一行调用就 panic
Kratos 启动时 kratos.New() 会立即触发配置加载，但若没提前注册 config.Provider，就会 panic 报 “no config provider registered”。这不是延迟加载失败，而是根本没入口。
- 必须在
func main()最开头调用conf.Load(config.NewFile("configs/app.yaml"))，不能塞在 logger 初始化之后、flag 解析中间，更不能放在某个 service 的 Init 函数里 -
configs/app.yaml路径要真实存在且可读；conf.Load()返回 error 时必须显式检查并os.Exit(1)，否则后续 panic 会掩盖真正原因 - 别指望环境变量自动替换，
config.NewFile(os.Getenv("CONFIG_PATH"))得自己拼完整路径，Kratos 不解析${CONFIG_PATH}这类语法
wire.go 里 InitializeApp 缺失或 wire.Build 失败
kratos run 找不到 InitializeApp，不是命令输错了，而是 cmd/server/wire.go 没生成或被误删——这是 kratos new 后最常漏检的点。
- 打开
cmd/server/wire.go，确认存在func InitializeApp() *app.App声明；它由wire.Build生成，不是手写的 - 如果删过
wire.go或改过wire.Build参数，立刻执行wire命令重生成（确保已安装github.com/google/wire/cmd/wire） - 执行
go mod tidy再跑kratos run；官方模板的go.mod可能与本地 Go 1.21+ 不兼容，tidy会修正依赖版本
自定义中间件构造函数里访问了 nil 依赖
中间件 panic 导致服务启动直接崩溃，常见于 middleware.Middleware 返回的闭包外就调用了 log.NewHelper(logger) 或做了非法类型断言——Kratos 不 recover 中间件 panic，它会直接冒泡到 main goroutine。
- 所有中间件构造函数参数必须做非空校验：比如
if logger == nil { panic("logger required") } - 不要在闭包外提前初始化 helper：
log.NewHelper(logger)必须放到 Handler 内部首次使用前再调，否则logger为 nil 就 panic - 避免对
req做(*http.Request)断言；Kratos HTTP 中间件接收的是*bm.Context或其他 transport 封装体，正确方式是用transport.FromServerContext(ctx)获取 transporter
proto 生成缺失 Register 方法或字段未定义
报错 “undefined: xxxRequest” 或 “unknown field 'xxx' in conf.Config”，基本锁定在 proto 编译环节——不是代码写错了，是工具链没对齐。
- 确认
protoc --version≥ 3.21；低于此版本会导致api/下的.pb.go缺失字段 -
protoc-gen-go必须是 v1.31（不是 v1.32+），新版因接口变更会跳过生成，只留下空的conf.pb.go - 检查
internal/conf/conf.proto是否存在，且其go_package声明与生成的internal/conf/conf.pb.go包路径一致；不匹配会导致conf.Load()panic
真正难排查的从来不是错误信息本身，而是 panic 发生在构造函数里、日志还没起来、debug server 没启就挂了——所以启动阶段所有依赖都得在 panic 前做显式校验，而不是靠后续日志兜底。
