不能直接在同一个端口上同时跑 gRPC 和 REST，因为 gRPC 基于 HTTP/2 且依赖专用 handler 处理 application/grpc 流量，而标准 HTTP/1.1 的 REST 服务无法识别或解包其二进制帧，会导致连接拒绝、404 或 GOAWAY 错误。
为什么不能直接在同一个端口上同时跑 gRPC 和 REST
gRPC 默认使用 HTTP/2 协议，而大多数 REST 客户端（如 curl、浏览器、axios）走的是 HTTP/1.1；两者在协议层不兼容。如果你强行把 grpc.Server 和 http.ServeMux 注册到同一个 http.Server 上，会遇到连接被拒绝、404 或 HTTP/2 error: client sent GOAWAY 等问题。
根本原因在于：gRPC 服务端依赖 grpc.Server 的特殊 handler（grpc.NewServer().ServeHTTP），它只响应以 application/grpc 为 Content-Type 且启用 HTTP/2 的请求；而标准 http.ServeMux 不识别这种流量，也无法解包 gRPC 的二进制帧。
推荐方案：单进程双端口 + 共享业务逻辑
最稳妥、可维护性最高的做法是启动两个独立的 http.Server 实例，分别监听不同端口，但复用同一套 service 层代码。这样避免协议冲突，也便于后续拆分或灰度发布。
- gRPC 服务监听
:9000（或其他非 80/443 的端口），使用grpc.Server启动 - REST API 监听
:8080，使用http.ServeMux或gin.Engine/echo.Echo等框架封装 - 两者都调用相同的
*service.UserService、*repository.UserRepo等结构体，不重复实现业务逻辑 - 共享中间件（如日志、认证、指标）可通过封装统一函数注入，例如
LogMiddleware(http.Handler) http.Handler
如何用 grpc-gateway 实现“一套 proto 生成 REST 接口”
如果你希望 REST 接口语义和 gRPC 方法严格对齐（比如 POST /v1/users 对应 CreateUser RPC），grpc-gateway 是目前 Go 生态最成熟的方案。它不是代理，而是基于 proto 文件生成反向代理式的 HTTP 路由处理器。
立即学习“go语言免费学习笔记（深入）”；
关键点：
- 必须在 proto 中用
google.api.http扩展声明 REST 映射，例如：rpc CreateUser(CreateUserRequest) returns (CreateUserResponse) { option (google.api.http) = { post: "/v1/users" body: "*" }; } - 生成时需同时运行
protoc生成 gRPC stub 和 gateway stub：protoc --go_out=. --go-grpc_out=. --grpc-gateway_out=. api.proto - 启动时，将 gateway 的
handler注册到普通http.ServeMux，再由同一个http.Server托管 —— 注意：此时该 server 必须启用 HTTP/2（用于 gRPC over HTTP/2），但 gateway 本身走 HTTP/1.1，所以要显式配置：server.TLSConfig = &tls.Config{NextProtos: []string{"h2", "http/1.1"}} - 不要把 gateway handler 和 gRPC server 混在同一个
http.ServeMux下直接 Serve；正确方式是用runtime.NewServeMux()创建独立 mux，并通过grpc.Dial连接本地 gRPC server（即让 gateway 反向调用本进程的 gRPC 端口）
常见陷阱与绕不过去的细节
实际落地时，这几个点最容易导致线上行为异常：
-
grpc-gateway默认不传递 gRPC metadata 到后端，如果鉴权信息存在 header（如Authorization: Bearer xxx），需手动注册runtime.WithIncomingHeaderMatcher并在 handler 中提取塞入 context - gRPC 流式接口（
stream）无法被grpc-gateway映射为 REST，只能降级为 polling 或改用 WebSocket - 错误码映射不完全：gRPC 的
codes.NotFound会被转成 HTTP 404，但自定义状态码（如codes.Aborted）默认变成 503，需用runtime.WithErrorHandler重写 - 超时控制分离：HTTP server 的
ReadTimeout不影响 gRPC stream 的生命周期；gRPC client 的ctx.WithTimeout也不影响 gateway 的 HTTP 连接空闲超时，两者必须分别配置
真正麻烦的从来不是“能不能同时提供”，而是“怎么让两套协议下的错误处理、上下文传递、可观测性保持一致”。别省略日志字段对齐、traceID 透传、metric 标签标准化这些事——它们比选型重要得多。
