kratos new 是唯一可靠方式，执行前须校验 protoc≥3.21、protoc-gen-go=v1.31、go111module=on 且 goproxy 已配置；否则项目骨架不可运行，错误常静默出现。
kratos new 是唯一可靠方式，其他操作大概率导致 wire 注入失败、proto 生成空文件或配置加载 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接口变更，会跳过生成，只留下空的conf.pb.go -
GO111MODULE=on且GOPROXY=https://goproxy.cn（或https://www.php.cn/link/b6512ba2ef13d7241ba28dbf20bff5a7）；国内未设代理时，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 四者之间的强一致性。
第一次 kratos run 失败最常卡在路径和模块上
常见现象是报 "failed to load config" 或找不到 wire.go：
- 务必在项目根目录执行命令，不要进到
cmd/server下运行kratos run；它需要读取configs/config.yaml和顶层wire.go - 执行
go mod tidy再跑；官方模板的go.mod可能与你本地 Go 1.21+ 不兼容，tidy会自动修正依赖版本 - 别手动删
go.mod后再go init；这会破坏 Kratos 对模块路径的约定（如helloworld必须对应module helloworld），wire 注入和 proto import 全部失效
真正容易被忽略的是：kratos new 生成的结构不是“可运行的终点”，而是“契约关系的起点”。任何跳过它、改它、绕过它的操作，都会让 proto 字段、wire 类型断言、配置字段绑定三者脱节——问题不会立刻报错，而是在某次字段新增或服务重启时突然 panic。
