beego 不支持 grpc 原生集成，需分离端口：beego 处理 http（如 8080），grpc 单独监听（如 9000）；controller 中调用 grpc 客户端须复用连接、传带超时的 context 并及时 cancel。
Beego 本身不支持 gRPC 服务端或客户端原生集成 —— 它是 HTTP/1.1 为主的 MVC Web 框架，没有内置 protobuf 编译、HTTP/2 多路复用、流式方法注册等 gRPC 必需能力。想在 Beego 项目里“用上 gRPC”，必须明确分工：Beego 做 HTTP API 层（如管理接口、前端聚合），gRPC 单独跑服务端/客户端，二者通过标准 Go 代码互通。
beego 项目里直接注册 gRPC Server 会失败
常见错误现象是调用 grpc.NewServer() 后绑定到 Beego 的监听端口（比如 8080），结果服务启动但无法响应 gRPC 请求，curl 或 grpcurl 连接超时，甚至 Beego 的 HTTP 路由也一并失效。
根本原因：Beego 使用 http.Server 启动，而 gRPC Server 依赖 http2.Server 和 ALPN 协商，两者监听同一端口会冲突；Beego 也不接管 HTTP/2 Upgrade 流程，无法透传 gRPC 的二进制帧。
- 不要在
beego.Run()前后手动调用grpc.Serve()绑定相同端口 - 若强行共用端口，需自己实现
http.Handler分发逻辑（判断content-type: application/grpc），但 Beego 无钩子拦截原始 request body，实际不可靠 - 正确做法：gRPC Server 单独监听一个端口（如
9000），Beego 保持8080只处理 HTTP
Beego Controller 中调用 gRPC 客户端要小心 context 和 timeout
这是最常用且可行的组合：Beego 提供 REST 接口，内部用 Go 原生 gRPC 客户端访问后端微服务。但容易因配置不当导致阻塞、泄漏或超时失控。
关键点：
- gRPC 客户端连接应复用，不要每次请求都
grpc.Dial()；建议在 Beegoinit()或AppStart钩子中初始化并存为全局变量或注入到 Controller - 必须显式传入带 timeout 的
context.Context，例如ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)；否则默认无超时，上游 HTTP 请求已断开，gRPC 调用仍在后台跑 - 记得调用
cancel()，避免 goroutine 泄漏；Beego 的Finish()钩子适合放这里 - 错误处理不能只看
err != nil，还要检查status.Code(err)是否为Canceled或DeadlineExceeded，对应返回合适的 HTTP 状态码（如 504）
proto 文件生成的 Go 代码如何与 Beego 项目共存
Beego 项目结构默认不含 protos/ 目录，也不会自动运行 protoc。你需要手动组织，否则编译报错 cannot find package "xxx" 或类型未定义。
推荐做法：
- 在项目根目录下新建
proto/文件夹，放入xxx.proto；同时建pb/目录存放生成代码 - 用 Makefile 或脚本封装生成命令：
protoc --go_out=plugins=grpc:. --go_opt=paths=source_relative proto/*.proto - 确保
go.mod中 module 名与option go_package一致，例如option go_package = "myapp/pb";，则生成文件需放在pb/下，且 import 路径为"myapp/pb" - Beego 的
controllers/中 import"myapp/pb"即可使用生成的 client 和 message 类型
Beego + gRPC 混合部署时的健康检查和可观测性盲区
Beego 自带的 /healthz 只检查自身 HTTP 服务是否存活，对它所依赖的 gRPC 后端完全无感知。线上经常出现 Beego 接口返回 200，但下游 gRPC 已宕机，用户看到的是空数据或错误提示。
必须手动补全：
- 在 Beego 的健康检查 handler（如
HealthController.Get()）中，主动调用一次关键 gRPC 方法（如CheckAlive()），并设置短 timeout（500ms） - 把 gRPC 连接状态缓存起来（如用
sync.Once+ 原子 bool），避免每次健康检查都建连 - 日志中要区分记录：Beego 入口耗时、gRPC 调用耗时、gRPC 错误码；否则排查慢请求时无法定位是 HTTP 层还是 RPC 层问题
真正的难点不在代码怎么写，而在于你得始终记住：Beego 和 gRPC 是两个独立生命周期的系统，它们之间没有框架级粘合，所有通信都靠你手写的 Go 代码兜底 —— 少一个 context.WithTimeout，少一次 defer cancel()，就可能在线上拖垮整个接口。
