Kratos 的认知门槛在于项目结构、proto 定义和 wire 注入三关：proto 是 API 契约原点，强制接口先行并生成路由/校验/文档；wire 在编译期显式声明依赖树，类型与构造函数必须严格匹配；目录分层（api/internal/cmd/configs）体现“约定优于配置”与上下层单向依赖，而非技术复杂度本身。
kratos new 命令能跑通，不等于上手了 Kratos。真正卡住人的不是命令行，而是项目结构、proto 定义、wire 注入这三关——它们共同构成 Kratos 的“认知门槛”，而不是“技术门槛”。
为什么 kratos new helloworld 成功后反而更困惑？
因为官方模板默认按分布式场景组织，但新手拿到的是一个“全量压缩包”：注册中心、etcd 配置加载、gRPC + HTTP 双协议、中间件链、日志埋点、错误码生成……而你只想写个 /users 接口查数据库。
- 目录里
api/下一堆*.pb.go文件，但greeter.proto里连个user_id字段都没有，改哪？ -
internal/biz和internal/data看起来像分层，但没注释、没示例，BizStruct和DataStruct到底谁该调用谁？ -
wire.go里全是wire.Build(…)调用，但删掉任意一行就编译失败，又不知道它到底在组装什么。
proto 不是可选项，是 Kratos 的 API 原点
Kratos 把接口契约提前到代码编写之前——所有 HTTP 路由、gRPC 方法、参数校验、错误码、Swagger 文档，都从 .proto 文件生成。这不是炫技，是强制统一契约表达。
- 改接口必须先改
api/helloworld/v1/greeter.proto，再执行make proto（或kratos proto client）重新生成 Go 代码；直接改greeter_http.pb.go会被下次生成覆盖。 -
google.api.http扩展必须显式 import，否则get: "/helloworld/{name}"这种路由不会生效，HTTP Server 启动后 404。 - 参数校验如
[(validate.rules).string.min_len = 1]是运行时生效的，但需要在main.go中显式注册validator中间件，否则校验逻辑压根不触发。
wire 编译期注入不是黑盒，但得看清依赖图
wire 不是 Spring 那种运行时反射注入，它在编译前就生成 wire_gen.go，把所有 NewXXX() 调用串成一棵树。问题常出在“漏传依赖”或“类型不匹配”。
- 常见报错：
cannot use xxx (type *data.UserRepo) as type *biz.UserUsecase in argument to biz.NewUserUsecase—— 实际是构造函数签名和wire.Bind声明对不上。 -
wire.NewSet必须显式列出所有依赖项，比如data.NewUserRepo和data.NewData都要出现在同一组Set里，否则NewUserUsecase拿不到*data.Data实例。 - 别手动改
wire_gen.go。它每次wire命令都会重写，只改wire.go里的Build和NewSet。
单体项目起步，建议绕开原生模板直接用 kratos-bootstrap
如果你只是想快速验证业务逻辑，或者落地一个内部管理后台，kratos-bootstrap（GoWind Admin 提供）比原生 kratos-layout 更合适——它默认关闭服务注册、配置中心、gRPC 等分布式模块，启动即 HTTP + 数据库 + 日志。
- 不需要删
registry相关 import，也不用注释掉etcd.New初始化逻辑；kratos-bootstrap在封装层已做场景隔离。 - 配置加载支持
config.yaml本地文件优先，环境变量覆盖，无需接入 Nacos/Etcd 就能热更新。 - 组件集成方式类比 Spring Boot Starter：
bootstrap.WithDatabase()、bootstrap.WithHTTPServer()，不用手写wire组装树。
