iris不能整合grpc，只能双端口共存；因其仅支持http/1.1，而grpc必须运行于http/2，协议不兼容导致无法注册grpc.server到iris路由或代理grpc流量，否则返回400或断连。
不能整合，只能共存。 Iris 是纯 HTTP/1.1 框架，而 gRPC 必须运行在 HTTP/2 上；你无法把 grpc.Server 注册进 Iris 路由，也不能用 iris.Any() 代理 gRPC 流量——那样会触发 400 Bad Request 或直接断连。
为什么 Iris.Listen() 不能和 gRPC 共用一个端口
Iris 底层调用的是 http.ListenAndServe，它只处理 HTTP/1.x 请求。gRPC 使用 HTTP/2 的帧格式（如 HEADERS、DATA、RST_STREAM），这些帧会被 net/http 当作非法请求拦截并拒绝。即使你强行在 Iris 启动后调用 grpc.NewServer().Serve()，也会因端口已被占用或协议不兼容而 panic 或静默失败。
- HTTP/2 多路复用、流控、头部压缩等特性，
net/http在 Go 1.26 中仍不支持服务端主动降级或混合协议监听 - 试图用
iris.WrapRouter()或中间件“劫持”原始连接去喂给 gRPC —— 不可行：Iris 不暴露底层net.Conn控制权 - Kubernetes Ingress 或 Nginx 默认也不转发 HTTP/2 原生流量，除非显式配置
http2 on和proxy_http_version 2.0
双端口共存时怎么共享业务逻辑
让 Iris 和 gRPC Server 在同一进程里跑两个监听器，但各自独立处理网络层。关键在于把数据库连接池、缓存客户端、配置中心等依赖抽成全局变量或依赖注入容器，而非耦合在 handler 或 service 实现里。
- 启动顺序要错开：先
net.Listen("tcp", ":50051")启 gRPC listener（非阻塞），再iris.Listen(":8080")；否则 Iris 阻塞主线程会导致 gRPC 启不动 - 用
goroutine包裹 gRPC 启动：go func() { s.Serve(lis) }()，避免阻塞 Iris 初始化 - 业务结构体（如
*UserService）应只依赖接口（DBer,CacheClient），而不是具体实现，方便测试和替换 - 不要在 gRPC handler 里调用
iris.Context相关方法——它们根本不可用
proto 生成代码后如何在 Iris 项目里调用其他 gRPC 服务
此时 Iris 只是 gRPC 客户端宿主，和框架本身无关。重点是连接管理、超时控制和错误分类，不是路由或中间件集成。
- 全局复用一个
*grpc.ClientConn：在main()初始化时grpc.Dial()一次，注入到所有需要的服务中 - 每次调用必须带
context.WithTimeout()，例如ctx, cancel := context.WithTimeout(ctx, 2*time.Second)；调用完立刻cancel() - 错误判断别只看
err != nil：用status.Code(err)区分codes.Unavailable（连不上）、codes.NotFound（服务名错）、codes.InvalidArgument（参数校验失败） - 如果调用目标是 Python/Java 服务，确认对方启用了明文（
insecure=True）或你已配好 TLS 证书路径，否则 Go 客户端会卡在Connecting状态
最容易被忽略的是部署侧：K8s Service 必须声明两个 ports，且 appProtocol: grpc 要写在 gRPC 端口上，否则 Istio 或 Cilium 无法识别协议做 mTLS 升级。开发时本地能通，上环境就 UNAVAILABLE，八成是这个没配。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
