kratos new 是唯一可靠方式，其他操作会导致 wire 注入失败、proto 生成空文件或启动 panic；执行前须校验 protoc≥3.21、protoc-gen-go=v1.31、GO111MODULE=on 且 GOPROXY 已配置，否则项目骨架不可运行且错误常静默出现。
kratos new 是唯一能生成可用模板的方式，其他任何替代操作都会导致 wire 注入失败、pb.go 为空或启动 panic。
kratos new 前必须校验的三个环境项
不满足任一条件，项目骨架建出来也跑不起来，而且错误常静默发生（比如只生成一个空目录）：
-
protoc --version必须 ≥ 3.21；低于此版本，api/下生成的.pb.go文件会缺失字段，后续kratos run报"undefined: xxxRequest" -
protoc-gen-go必须是 v1.31（不是 v1.32+）；新版因google.golang.org/protobuf接口变更，会跳过生成，导致internal/conf/conf.pb.go为空 -
GO111MODULE=on且GOPROXY已设（推荐https://goproxy.cn）；国内未配代理时，kratos new拉kratos-layout模板会超时，无报错、无提示、只留空文件夹
生成后立刻验证的两个关键文件
项目目录建出来 ≠ 能跑。90% 的首次启动失败，都卡在这两处没检查：
- 确认
internal/conf/conf.proto存在，且其go_package声明与生成的internal/conf/conf.pb.go包路径一致；否则conf.Load()会 panic，报错"unknown field 'xxx' in conf.Config" - 打开
cmd/server/wire.go，确认存在func InitializeApp()；这是 Wire 依赖注入的入口函数，若被删或未生成，kratos run直接报"undefined: InitializeApp"，而非配置类提示
为什么不能用 blades new 替代 kratos new
blades 是增强工具链，不是项目生成器。它默认从 GitHub 远程拉模板，国内网络下极易触发 "template not found: kratos-layout" 错误，且无本地缓存 fallback；而 kratos new 内置稳定模板缓存（存于 $HOME/.kratos/repo/），首次成功后，后续新建极速完成。强行用 blades new，等于绕开契约起点，直接破坏 proto → pb.go → wire.go → config.yaml 四者之间的强一致性。
最易被忽略的其实是 go.mod 兼容性——Kratos 模板生成的依赖版本可能与你本地 Go 1.21+ 不匹配，kratos run 前务必先执行 go mod tidy，否则连 wire.go 都找不到。
