kratos new 是必需步骤，跳过会导致 conf.load() panic 或 initializeapp 未定义；必须确保 internal/conf/conf.proto 存在并生成 conf.pb.go，且 wire.go 中含 initializeapp 函数；protoc ≥3.21、protoc-gen-go 用 v1.31+（非 v1.32+）；kratos proto server -t 参数须选 internal/service 或 internal/biz。
直接用 kratos new 初始化项目，跳过这一步手动搭结构大概率会在 conf.Load() panic 或 InitializeApp 未定义时卡住——这不是配置问题，是 Kratos 的契约机制被绕过了。
kratos new 必须验证的两个生成物
项目目录建出来不等于能跑。很多团队在 kratos run 报错后反复调配置，其实失败点早在生成阶段就埋下了：
-
internal/conf/conf.proto必须存在，且其生成的conf.pb.go要被conf.Load()正确加载；缺它会导致启动时 panic “unknown field 'xxx' in conf.Config” -
cmd/server/wire.go中必须有InitializeApp函数声明；这是 Wire 依赖注入的入口，删了或没生成，kratos run直接报 “undefined: InitializeApp”
protoc 和 protoc-gen-go 版本不能乱配
Kratos v2.x 对工具链版本敏感，不是“装了就行”，而是“装对才跑得通”：
-
protoc必须 ≥ 3.21，低于此版本会解析不了google/api/annotations.proto -
protoc-gen-go必须用 v1.31+，但不能用 v1.32+ —— 后者因google.golang.org/protobuf接口变更，会导致api/下.pb.go文件编译失败 - 验证方式：
protoc --version和protoc-gen-go --version都要查，别只信 go install 命令输出
kratos proto server 生成 service 代码时的 -t 参数
这个参数决定生成的服务逻辑放在哪一层，选错位置会导致依赖注入失效或编译报错：
-
-t internal/service：标准写法，生成的 service 实现会放进internal/service/，自动接入 Kratos 的 Service 层契约 -
-t internal/biz：适合业务逻辑强、需复用的场景，但要手动补service.NewXXXService工厂函数，否则wire.go找不到构造入口 - 别用
-t internal/data或-t internal/api：前者是数据访问层，后者只放接口定义，放 service 代码会破坏分层，后续加中间件或 mock 测试都容易出问题
第一次 kratos run 失败，先看日志里有没有 “failed to load config”
90% 的首次启动失败不是代码写错了，而是配置加载链断在了最前面：
- 确认
configs/config.yaml存在，且内容格式合法（YAML 缩进、冒号后空格） - 检查
conf.proto里定义的字段名是否和config.yaml中的 key 完全一致（大小写、下划线） - 如果用了
env:占位符（如port: ${HTTP_PORT:8000}），确保环境变量已导出，或改用硬编码先跑通
真正麻烦的不是生成代码，而是生成后的结构是否与 Kratos 的 wire 注入、conf 加载、proto 绑定三者严丝合缝——漏掉任意一环，错误信息都不会直说“你少了个文件”，只会抛个模糊 panic 或 undefined 符号。
