Kratos本身不提供网关功能，所谓“Kratos网关”只有两种路径：用fregata做独立网关服务，或用Kratos手写BFF层；硬塞路由规则、middleware等无法解决协议转换与跨服务聚合问题。
Kratos 本身不提供网关功能，所谓“Kratos 网关”只有两种现实路径：用 fregata 做独立网关服务，或用 Kratos 框架手写 BFF 层。硬要在 Kratos 服务里塞路由规则、middleware、selector，解决不了协议转换和跨服务聚合问题，只会让架构越来越难维护。
fregata 启动失败却没报错？检查 proto 和配置字段拼写
fregata 不是靠反射猜逻辑，它必须加载 .proto 文件才能生成 HTTP ↔ gRPC 的映射规则。没 proto，它就退化成透明 HTTP 反向代理，失去 Kratos 生态价值。
-
proto文件必须放在fregata进程可读路径下，推荐统一放./api/proto - 启动命令必须显式指定：
fregata --proto-dir=./api/proto --config=config.yaml -
package名和service名要与下游 gRPC Server 的定义完全一致，大小写、下划线都不能错，否则请求直接 404 - 配置文件里字段名极其敏感：
endpoints写成endpoint、host写成hostname，fregata 会静默跳过该路由，日志里不提示、也不 panic
kratos.New() 一运行就 panic？三件事漏一件都不行
kratos.New() 不是初始化函数，它是“启动检查器”——缺任何一项基础依赖，立刻 panic，且错误信息极不友好。
- 必须在
main()第一行调用conf.Load()，不能等 flag 解析完或日志初始化后再做 -
conf.Load()必须传至少一个config.Provider，比如config.NewFile("configs/app.yaml")；别指望os.Getenv("CONFIG_PATH")被自动展开 - 必须提前创建
http.Server和/或grpc.Server实例，并完整传入kratos.New(kratos.Server(httpSrv, grpcSrv))；漏传grpcSrv就等于没开 gRPC 端口 - 如果只走 HTTP，就别调
service.Register()——它只对本进程内已运行的grpc.Server生效，跟 REST 接口无关
proto 编译后没有 RegisterXXXServiceServer？插件装错了
Kratos 的 gRPC 注册函数（如 RegisterDeviceServiceServer）不是 protoc-gen-go 生成的，那是旧版 gRPC 的产物。Kratos v2 要求两个插件协同工作：
- 必须同时安装
protoc-gen-go-grpc（v2 版本）和protoc-gen-go-http - 单独用
protoc-gen-go只生成*.pb.go，不生成 server 注册函数，也不生成 HTTP 映射逻辑 - 确认
protoc命令中--go-grpc_out和--go-http_out参数都存在，且输出路径一致
真正容易被忽略的是：fregata 的配置生效与否，几乎全靠字段名拼写和 proto 包名一致性；而 Kratos 服务启动失败，往往卡在 conf.Load() 的调用时机和 provider 注册顺序上——这两处没日志、没堆栈、不报路径，纯靠经验定位。
