不能直接启动多个Server实例，因为HTTP、gRPC、WebSocket各自管理连接生命周期，缺乏统一启停协调机制，导致生命周期错乱、中间件不复用、错误码不统一、健康检查口径不一致。
Go 微服务系统要做多协议支持，不能靠堆砌 net/http、grpc.Server、websocket.Upgrader 三个独立实例然后各自 ListenAndServe —— 这样必然导致生命周期错乱、中间件不复用、错误码不统一、健康检查口径不一致。
为什么不能直接启动多个 Server 实例
常见错误现象是：HTTP 服务已关闭，但 gRPC 连接还在写入响应；或者 WebSocket 升级后，HTTP 中间件提前读了 r.Body 导致 upgrader.Upgrade() 失败并静默返回 200；更隐蔽的是信号中断时，gRPC 的 GracefulStop() 和 HTTP 的 srv.Shutdown() 执行顺序颠倒，造成请求丢失。
根本原因在于：http.Server、grpc.Server、websocket.Upgrader 各自管理连接生命周期，没有统一的启停协调机制。它们不是“并列组件”，而是需要被同一个容器调度的“监听器”。
- HTTP 和 gRPC 都依赖底层
net.Conn，但http.Server会消费conn.Read()直到遇到\r\n\r\n，而grpc.Server要求连接以PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n开头 —— 两者不可共存于同一未分流的监听器 - WebSocket 升级必须发生在 HTTP 生命周期内，且不能有任何中间件提前读取 body
- 所有协议都该共享同一套配置加载、日志上下文、指标上报和信号监听逻辑
必须用 Listener 接口抽象协议入口
把每种协议封装成一个满足 Listener 接口的类型，而不是裸写 http.ListenAndServe 或 grpc.Serve：
立即学习“go语言免费学习笔记（深入）”；
type Listener interface {
Addr() string
Protocol() string // 返回 "http" / "grpc" / "ws"
ListenAndServe() error
Shutdown(context.Context) error
}实操建议：
- HTTP Listener 封装
http.Server，但ListenAndServe不直接调用，而是交给顶层 App 容器统一触发 - gRPC Listener 持有
*grpc.Server，Shutdown必须调用GracefulStop()（不是Stop()），且需等待其完成后再让其他 Listener 关闭 - WebSocket 不单独建 Listener，它属于 HTTP 协议的子路径，由 HTTP Listener 内部通过
http.HandlerFunc在路径匹配后调用upgrader.Upgrade() - 所有 Listener 的
Addr()必须可配，避免硬编码"0.0.0.0:8080"，方便测试和灰度
业务逻辑必须与协议完全解耦
典型错误是把 http.ResponseWriter 或 grpc.ServerStream 传进 service 层，导致无法复用或测试困难。正确做法是定义纯 Go 接口：
type UserService interface {
CreateUser(ctx context.Context, req CreateUserRequest) (CreateUserResponse, error)
}协议适配层只做三件事：解析、调用、格式化。例如：
- HTTP adapter：从
*http.Request解析 JSON body → 构造CreateUserRequest→ 调用svc.CreateUser()→ 写 JSON 响应 + 状态码 - gRPC adapter：实现
pb.UserServiceServer接口，把pb.CreateUserRequest转成CreateUserRequest→ 调用 service → 把结果转成pb.CreateUserResponse - 错误统一用
AppError类型，含HTTPStatus和GRPCCode字段，adapter 根据当前协议选择映射方式，service 层绝不出现status.Codef或http.Error
单端口多协议分流必须绕过 http.Server
当需要在同一个端口（如 8080）同时支持 HTTP、gRPC、WebSocket 时，http.Server 无法识别 gRPC 的 PRI 帧或 WebSocket 的 Upgrade 请求 —— 它会直接返回 404 或 panic。
实操方案是自己实现 net.Listener 包装器，在 Accept() 后读取前几个字节做协议探测：
- 读 16 字节缓冲，判断是否以
"PRI * HTTP/2.0"开头 → 分发给grpc.Server - 是否含
"GET /ws HTTP/1.1\r\nUpgrade: websocket"→ 分发给http.Server（后续由 handler 升级） - 其余走标准 HTTP 流程
- 务必对每个
conn设置SetReadDeadline，否则探测阻塞会导致连接堆积
这个层面的协议识别没法靠中间件或路由库完成，必须下沉到连接建立瞬间 —— 这也是为什么所有“单端口多协议”生产网关（如 Envoy、Gin+grpc-gateway 组合）都绕不开自定义 Listener。
