Go-Kratos Gateway（即Fregata）是独立网关服务，非Kratos框架内置模块；Kratos本身仅提供微服务通信能力，不具备协议转换、全局限流等网关核心功能，必须手动集成Fregata或用Kratos开发BFF层。
Go-Kratos Gateway 不是独立服务，而是 Kratos 生态中可插拔的网关能力模块；直接用 kratos new 生成的项目默认不含网关，必须手动集成或部署独立的 fregata 实例。
为什么不能直接在 Kratos 服务里启用“网关模式”
Kratos 本身是微服务框架，不是网关产品。它的 http.Server 和 grpc.Server 是面向后端服务暴露的，不具备请求聚合、协议转换、全局限流等网关核心能力。所谓“Kratos 网关”，实际指两个不同东西：
– fregata：官方维护的独立网关服务（Go-Kratos Gateway 的正式名称）
– BFF 层：用 Kratos 框架写的业务聚合层，常被误称为“网关”
常见错误现象：
– 在 main.go 里给 http.Server 加一堆路由规则，以为这就是网关
– 把 middleware 当成网关功能，结果发现无法做跨服务协议转换（如 HTTP → gRPC）
– 试图用 Kratos 的 selector 或 resolver 实现动态上游发现，但缺少统一配置中心支持
fregata 启动时必须加载 proto 文件才能做协议转换
fregata 的核心能力（HTTP ↔ gRPC 转换）依赖于 proto 定义。它不是靠反射或约定，而是解析 .proto 文件生成反向代理逻辑。没 proto，就只能做透明 HTTP 转发，失去 Kratos 生态最大优势。
立即学习“go语言免费学习笔记（深入）”；
实操要点：
– proto 文件必须放在 fregata 可访问路径下，推荐统一存到 ./api/proto
– 启动命令需显式指定：fregata --proto-dir=./api/proto --config=config.yaml
– proto 中 package 名和 service 名必须与下游 BFF 的 gRPC Service 严格一致，否则 404
– 若 proto 有 google.api.http 注解，fregata 才能自动映射 HTTP 路径到 gRPC 方法
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
路由配置写错一个字段，fregata 就会静默跳过该路由
fregata 的配置文件（YAML）对字段名极其敏感。比如把 endpoints 写成 endpoint，或把 host 写成 hostname，不会报错，但对应路由完全不生效，日志也无提示。
容易踩的坑：
– upstream 下必须是 hosts 数组，不能是单个字符串
– timeout 单位是毫秒，但文档没明说，填 5s 会被忽略
– match 规则中 path 必须以 / 开头，method 必须大写（GET，不是 get）
– 多个路由规则顺序不重要，但 path 冲突时，fregata 不报错也不警告，只取第一个匹配项
BFF 层用 Kratos 写比用 Gin 更适合对接 fregata
当 fregata 把 HTTP 请求转成 gRPC 发给 BFF 时，BFF 用 Kratos 实现能天然复用中间件链、tracing 上下文、wire 注入体系；而 Gin 需要额外桥接 gRPC Server 和 HTTP 中间件，容易丢 traceID 或 context deadline。
关键差异：
– Kratos 的 http.Middleware 和 grpc.Middleware 共享同一套接口定义，BFF 可同时挂载鉴权/日志中间件
– Kratos 的 transport/http 和 transport/grpc 都支持 RequestID 自动注入，链路追踪完整
– Gin 默认没有 gRPC Server 支持，需手动注册 grpc.RegisterService，且无法复用 Kratos 的 error handling 机制（errors.New() → status.Code 转换）
真正复杂的地方在于：fregata 的配置粒度远细于代码逻辑，改一个路由规则要重启服务，而 Kratos BFF 的业务逻辑可以热更新；两者分工边界一旦模糊（比如在 BFF 里再做一次路由分发），整个链路就失去可观测性。
