kratos new是启动Kratos微服务项目的唯一正确起点，必须用它生成标准骨架，手动建目录或挪动文件会破坏wire注入、proto生成和配置加载的契约关系。
Kratos 项目结构不是靠手动拼凑出来的，而是由 kratos new 命令生成的标准骨架，硬改目录或挪动文件会导致 wire 注入失败、proto 生成路径错乱、配置加载异常。
必须用 kratos new 初始化，别手建目录
手动创建 internal/、api/、configs/ 等目录看似合理，但 Kratos 的代码生成和依赖注入强依赖约定路径：
-
kratos proto server默认只扫描api/**/v1/*.proto，且生成的RegisterXxxServer会写到internal/service/下对应包名路径 -
wire.Build在cmd/main.go中硬编码了internal/server、internal/service等导入路径，改名或移动就编译不过 -
conf.Load()默认尝试读取configs/config.yaml，路径写死在cmd/main.go的conf.NewFile("configs/config.yaml")里
api/ 和 internal/ 的职责边界不能模糊
这是最容易被破坏的分层逻辑，一旦混淆，proto 更新后代码无法再生、HTTP/gRPC 路由注册失效：
-
api/只放.proto文件，定义接口契约；不放 Go 代码，不 import 任何业务逻辑包 -
internal/service/是服务实现层，接收api/生成的 request struct，调用internal/biz/，返回api/生成的 reply struct -
internal/biz/是业务逻辑层，不依赖api/或internal/data/，只通过 interface 与上下层解耦 -
internal/data/是数据访问层，封装 DAO、Repo，对上只暴露 interface，具体实现（如 gorm、ent）放在data/xxx/子包里
配置文件位置和加载方式必须匹配默认行为
Kratos 启动时若找不到配置，conf.Load() 会 panic 报 no config provider registered，而不是提示“文件不存在”：
- 开发期：保持
configs/config.yaml存在，内容至少含name、server、registry一级 key；删掉它或改名就会启动失败 - 生产期：不要把敏感字段（如
database.password）写进configs/config.yaml，改用config.NewSource组合多个 source（如 file + secret），但主路径仍需保留空壳文件供conf.Load()初始化 - 别在
main()里用os.Getenv("CONFIG_PATH")拼路径——Kratos 不解析环境变量占位符，conf.NewFile(os.Getenv("CONFIG_PATH"))才有效
proto 编译命令必须带 paths=source_relative
不加这个参数，protoc 会把生成的 .pb.go 放到 GOPATH/src 下，导致 import 路径错乱、RegisterXxxServer 找不到：
- 正确命令：
protoc --go-grpc_out=paths=source_relative:. api/helloworld/v1/helloworld.proto - 错误命令：
protoc --go-grpc_out=. api/helloworld/v1/helloworld.proto（生成路径不可控） - 如果生成后报
undefined: RegisterHelloworldServiceServer，90% 是因为没装protoc-gen-go-grpc，只装了protoc-gen-go
项目结构的“规范”本质是让 Kratos 的自动化链路（proto → code → wire → run）能闭环运转，而不是追求视觉上的整齐。任何脱离 kratos new 骨架的调整，都要同步修复 wire、proto、conf 三处耦合点，否则很快会卡在 kratos run 启动失败或接口 404 上。
