gRPC 与 Fiber 不能共用同一 HTTP server 实例，因 Fiber 基于 HTTP/1.1 而 gRPC 依赖 HTTP/2，协议不兼容；须分离端口（如 Fiber :8080、gRPC :9001），独立启动，共享 service 层逻辑，统一健康检查与可观测性。
gRPC 和 Fiber 不能共用同一个 HTTP server 实例
直接在 fiber.App 的 Listen() 上启动 gRPC 服务会失败——Fiber 是基于标准 http.Server 的 HTTP/1.1 框架，而 gRPC 必须跑在 HTTP/2 上，两者协议不兼容。常见错误是调用 app.Listen(":9000") 后试图用 grpc.Dial("localhost:9000", ...) 连接，结果得到 connection refused 或 transport: authentication handshake failed。
正确做法是：gRPC 单独起一个 grpc.Server，监听独立端口（如 :9001）；Fiber 只负责 REST API，监听另一个端口（如 :8080）。两个 server 在同一进程内并行运行，但完全隔离。
- 不要复用
fiber.App的 listener 或http.Server实例去注册 gRPC handler - 避免用
fiber.App的中间件拦截 gRPC 流量——它无法解析 HTTP/2 帧，会直接丢弃请求 - 若需统一 TLS 终止，必须由反向代理（如 Nginx、Higress）前置处理，而非 Fiber 或 gRPC server 自己做
如何让 Fiber 客户端安全调用本地 gRPC 服务
Fiber 应用作为 gRPC 客户端时，grpc.Dial 的配置比写个 HTTP client 更关键。高频调用下若每次请求都新建连接，会迅速耗尽 socket 和 CPU。
推荐方式是：在 Fiber 启动时初始化一个全局 *grpc.ClientConn，并在所有 handler 中复用它。
立即学习“go语言免费学习笔记（深入）”；
- 使用
grpc.WithTransportCredentials(credentials.NewTLS(...))（生产环境必须启用 mTLS） - 禁用
grpc.WithBlock()，改用grpc.WithReturnConnectionError()+ 定期检查conn.GetState() == connectivity.Ready - 超时必须由 handler 内的
context.WithTimeout(ctx, 500 * time.Millisecond)控制，而非依赖 Dial 参数 - 务必在
app.Shutdown()阶段调用conn.Close()，否则 goroutine 和连接泄漏
Fiber 路由与 gRPC 接口如何共享业务逻辑
二者共存的核心价值不是“多暴露一套 API”，而是复用同一套领域逻辑。比如 /api/v1/users/{id}（Fiber）和 User.Get()（gRPC）应调用同一个 UserService.GetUserByID() 方法，而不是各自实现一遍。
结构上建议分层：handler 层（Fiber / gRPC）→ service 层（纯业务逻辑）→ repository 层（DB/Cache）。
- Fiber handler 解析 path/query/body 后，构造 domain 对象传给 service；gRPC handler 直接解包
*pb.GetUserRequest，也传给同一 service - 避免在 service 层引入
fiber.Ctx或grpc.ServerStream，否则耦合不可逆 - 错误统一转为自定义 error 类型（如
ErrNotFound），再由各自 handler 映射为 HTTP 状态码或 gRPC status.Code
混合部署时健康检查与可观测性怎么对齐
Kubernetes 中，Fiber 和 gRPC 必须提供**不同路径/端口/探针类型**的就绪与存活检查，否则滚动更新时会误判。
Fiber 的 /healthz 是 HTTP GET；gRPC 的健康检查必须走 grpc_health_v1.Health.Check，且需单独暴露 gRPC health 端口或复用 gRPC 主端口（推荐后者）。
- Fiber 就绪探针：HTTP GET
http://:8080/healthz，返回 200 表示可收流量 - gRPC 就绪探针：TCP 连通性 + gRPC health check，命令形如
grpc_health_probe -addr=:9001 - 日志上下文要打通：Fiber handler 中生成 trace ID，通过
metadata.MD注入 gRPC 调用，确保全链路可追踪 - 指标采集分开上报：Fiber 用
fiber.Handler中间件打点；gRPC 用otelgrpc.UnaryClientInterceptor，避免混用同一 metrics registry
Fiber 和 gRPC 共存本身不难，难的是连接生命周期、错误语义、可观测边界这三处容易被忽略的细节。尤其当服务开始横向扩展后，连接池未复用、健康探针错配、trace ID 断裂，会直接导致故障定位时间翻倍。
