kratos new 是唯一可靠起点，跳过它会导致启动时卡在配置加载或依赖注入，如报“unknown field 'server' in conf.Config”或“undefined: InitializeApp”；必须满足protoc≥3.21、protoc-gen-go=v1.31、GO111MODULE=on且GOPROXY已配置，并验证conf.proto与conf.pb.go一致性及wire.go中InitializeApp函数存在。
kratos new 是唯一可靠起点，跳过它直接手建目录、复制配置或改 go.mod，90% 会在启动时卡在配置加载或依赖注入环节，且错误信息极其隐蔽（比如 panic 报 “unknown field 'server' in conf.Config” 或 “undefined: InitializeApp”）。
kratos new 前必须对齐的三个环境条件
不是所有 Go 环境都能跑通 kratos new，失败往往不是命令问题，而是底层契约被破坏：
-
protoc ≥ 3.21且protoc-gen-go必须是v1.31.x——v1.32+因google.golang.org/protobuf接口变更，会导致api/下.pb.go文件缺失RegisterXXXServiceServer方法 -
GO111MODULE=on必须启用，否则go mod download会漏掉google.golang.org/grpc/cmd/protoc-gen-go-grpc等关键生成器 -
GOPROXY需设为https://goproxy.cn,direct（国内），否则拉取kratos-layout模板时超时静默失败，只留下空文件夹
生成后立刻验证的两个关键文件
项目目录生成 ≠ 可运行。很多团队卡在 kratos run 失败，其实问题出在生成后没做这两项检查：
- 确认
internal/conf/conf.proto存在，且已被internal/conf/conf.pb.go正确引用 —— Kratos 的配置结构体靠它生成，缺失会导致conf.Load()panic - 检查
cmd/server/wire.go中是否已声明InitializeApp函数 —— 这是 Wire 依赖注入的入口，若被误删或未生成，kratos run会报 “undefined: InitializeApp”，而不是更友好的提示
proto 生成后服务注册失败的常见原因
service.Register() 报错 rpc error: code = Unavailable desc = connection closed，本质不是网络问题，而是本进程内 gRPC server 未就位：
-
service.Register()是向本进程内grpc.Server实例注册，不是发请求给别的服务 - 必须确保
grpc.NewServer()已创建，并被加入app.Run()的server列表中 - 监听地址别写成
localhost:9000—— 容器或某些 macOS 网络栈下解析失败，应统一用0.0.0.0:9000 - 如果只用 HTTP，压根不需要
service.Register()；Kratos 的 HTTP 路由完全独立
配置加载 panic：“no config provider registered”
kratos.New() 启动时 panic，报 “no config provider registered”，是因为它内部调用 conf.Load() 但没提前注册源：
- 必须在
main()开头显式调用conf.Load()，并传入一个config.Provider，例如config.NewFile("configs/app.yaml") -
conf.Load()不自动识别环境变量，os.Getenv("CONFIG_PATH")得自己拼进去，不能指望它“猜” - 别跳过
c.Load()的错误检查 —— 如果返回 err，后续kratos.New()必然 panic
真正容易被忽略的是：Kratos 的配置加载、Wire 注入、proto 生成三者之间存在强耦合契约，任何一环手动干预（比如删了 conf.proto 又不重生成，或改了 wire.go 却忘了 go generate ./），都会导致启动失败，而错误堆栈往往指向下游（如 service 层），实际根因却在最开始那几行配置代码里。
