Gin 本身并不支持让单个 Engine 实例直接监听多个端口，因为它的 r.Run() 本质上封装的是单地址的 http.ListenAndServe()。如果要实现多端口监听，就需要创建多个 http.Server 实例，让它们各自绑定独立的 Addr 和 Handler。

其中 Handler 可以复用同一个 Engine，再通过 errgroup.Group 统一管理启停流程和错误处理。

Gin 本身不支持单个 Engine 实例直接监听多个端口——它的 r.Run() 只能启动一个 http.Server，这是底层 net/http 的限制，不是 Gin 的 bug 或设计缺陷。

为什么不能直接用 r.Run(":8080", ":8081")？

因为 r.Run() 内部调用的是 http.ListenAndServe()。该函数只接受一个地址参数，例如 ":8080"。

传入多个端口会编译报错或 panic；Gin 没有重载该方法，也不打算提供这种语法糖。

• r.Run() 是封装好的快捷启动方式，本质是创建并运行一个 http.Server，它不具备多监听能力
• 强行在一个 Engine 上复用多次 http.ListenAndServe() 会导致端口冲突、goroutine 竞态或 panic（比如重复调用 http.DefaultServeMux）
• 真正的多端口必须靠多个独立的 http.Server 实例，每个绑定自己的 Handler（可以是同一个 gin.Engine，也可以是不同路由树）

用 http.Server + errgroup.Group 启动多个端口

这是最轻量、最可控、也最常被生产环境采用的方式。

核心做法是：自己构造 http.Server，再用 errgroup.Group 统一管理 goroutine 生命周期和错误传播。

• 每个端口对应一个 http.Server，Addr 字段指定监听地址（如 ":8080"、":8081"）
• Handler 可以复用同一个 gin.Engine（适合统一逻辑），也可以分别初始化不同 gin.Engine（适合隔离路由/中间件）
• errgroup.Group 能确保任一服务退出时，其他服务也收到 cancel 信号，避免“半死”状态
• 必须显式调用 srv.Shutdown() 才能实现优雅关闭，srv.Close() 会粗暴中断连接

var g errgroup.Group
srv0 := &http.Server{Addr: ":8080", Handler: router01()}
srv1 := &http.Server{Addr: ":8081", Handler: router02()}

g.Go(func() error { return srv0.ListenAndServe() })
g.Go(func() error { return srv1.ListenAndServe() })

// 启动后阻塞等待任意错误
if err := g.Wait(); err != http.ErrServerClosed {
log.Fatal(err)
}

不同端口配不同中间件或路由分组的典型场景

常见需求不只是“换个端口”。更常见的是在同一进程里运行管理端口、API 端口和健康检查端口。

这些端口通常需要完全不同的中间件链和路由权限控制。

• API 端口（":8080"）：启用 gin.Recovery()、鉴权中间件、CORS、日志
• 管理端口（":8081"）：只允许内网访问，挂载 /debug/pprof、/rk/v1/healthy 等内部接口，禁用 Recovery
• Metrics 端口（":9090"）：仅暴露 /metrics，使用 promhttp.Handler()，不走 Gin 路由
• 注意：gin.Engine 是线程安全的，多个 http.Server 共享同一个 Engine 实例没问题，但中间件注册必须在 Engine 初始化阶段完成，不能动态增删

别踩 net.Listener 复用这个坑

有些人会先用 net.Listen("tcp", ":8080") 把 listener 创建出来，再把它传给多个 http.Server.Serve() 去共用。

结果往往并不如预期。轻则报 http: Server closed，重则直接触发 accept tcp: use of closed network connection 这样的 panic。

• http.Server.Serve() 会接管 listener 并循环 Accept()，多个 server 同时调用会争抢连接，必然出错
• 正确做法是每个 http.Server 自己调用 ListenAndServe()（内部自动创建 listener），或各自 net.Listen() + srv.Serve(lis)，但 listener 必须互不共享
• 如果真要复用底层 listener（极少见），得用 srv.Serve(ln) 配合自定义 ConnState 和连接池管理，复杂度远超收益，不推荐

上线前更需要关注什么

真正麻烦的从来不是“怎么启动多个端口”，而是“怎么让它们协同关闭、日志不打架、健康探针不互相干扰、TLS 配置不重复加载”。

这些细节一旦漏掉，上线后就会变成半夜的告警电话。

《夸克》非常好用的免费AI浏览器

下载APP查看