多实例部署Gin应用需进程隔离、独立配置与统一信号管理，核心是用errgroup.Group并发启动多个*http.Server并共用context控制生命周期，session必须用Redis外置存储，禁用memstore。
多实例部署 Gin 应用不是靠改 r.Run() 启动多个端口就完事的，核心在于进程隔离、共享资源协调和信号管理。单个进程里起多个 *http.Server 是可行的，但生产环境必须考虑优雅关闭、配置分离、日志隔离和 session 一致性 —— 尤其是 session 存储不能用 memstore。
多个 *http.Server 共存需用 errgroup.Group 统一生命周期
直接在 main 中并发调用 server.ListenAndServe() 会导致无法统一捕获退出信号，panic 时部分服务可能卡死。必须用 errgroup.Group 包裹所有 server 的启动逻辑，并共用一个 context.Context 控制退出时机。
常见错误现象：ctrl+c 后只有第一个服务退出，其余继续监听；或某服务 panic 导致其他服务未被通知而残留。
- 每个
*http.Server必须设置独立的Addr（如":8080"、":8081"），不能复用同一端口 -
ReadTimeout、WriteTimeout等参数应按服务 SLA 单独配置，避免相互干扰 - 所有 server 的
Handler必须是各自独立的*gin.Engine实例，不能共用同一个 router - 使用
errgroup.WithContext(ctx)初始化 group，确保 cancel 时所有 goroutine 被唤醒
session 多实例下必须用 Redis，禁用 memstore
memstore 是纯内存存储，每个 Gin 实例持有一份独立副本，用户在实例 A 登录后，请求被负载均衡到实例 B 就查不到 session —— 这不是“不一致”，而是根本不存在。
Redis 是唯一推荐的生产方案，它天然支持分布式读写，且 github.com/gin-contrib/sessions/redis 封装已成熟。
- 初始化 store 时，
redis.NewStore的连接池大小建议设为 10–30，避免连接耗尽 - key 的
authentication key和encryption key必须在所有实例间完全一致，否则解密失败返回空 session - session 过期时间（
MaxAge）要与 Redis 的 TTL 配合，建议显式调用session.Options(sessions.Options{MaxAge: 3600}) - 不要依赖
session.Save()自动刷新过期时间，显式调用session.Touch()才能延长 TTL
Docker Compose 编排多实例时注意网络与健康检查
用 Docker 启多个容器跑 Gin，本质仍是多个独立进程，但网络模型变了：不能再用 localhost 访问同机其他服务，必须通过 service name。
典型坑：redis://localhost:6379 在容器内连的是容器自己的 loopback，不是宿主机的 Redis。
- docker-compose.yml 中定义
redisservice，并让所有 Gin 服务通过redis:6379连接 - 每个 Gin 服务的 port 映射要错开，例如
"8080:8080"、"8081:8080"，避免宿主机端口冲突 - 添加
healthcheck，用curl -f http://localhost/health检查服务是否 ready，避免流量打到未启动完成的实例 - 若需共享配置文件（如 JWT 密钥、数据库 DSN），用
volumes挂载或env_file注入，不要硬编码进镜像
静态资源与 Swagger 文档需按实例隔离路径
多个 Gin 实例如果都挂载 /swagger/*，前端请求会因路由冲突或 CORS 问题失败；同样，router.Static("/static", "./assets") 若指向同一本地目录，在容器化场景下极易出现文件锁或权限错误。
根本原则：每个实例对外暴露的 HTTP 路径必须可区分，内部资源路径可共享但不可强依赖本地磁盘。
- Swagger 文档生成时用
swag init -o ./docs-8080和swag init -o ./docs-8081分开输出，再分别导入对应实例 - 静态资源优先走 CDN 或 Nginx 反向代理，Gin 只负责 API；若必须内置，用
router.StaticFS("/static/8080", http.Dir("./assets-8080"))做前缀隔离 - 模板渲染若用
multitemplate，各实例的templates/目录必须物理隔离，避免热更新时互相覆盖 - 日志文件路径也要按实例名区分，比如
logs/app-8080.log，否则多个进程写同一文件会乱序或丢日志
真正麻烦的从来不是启动几个服务，而是让它们在崩溃、重启、扩容缩容时不互相拖垮 —— 关键点永远落在：共享状态（session/缓存）必须外置、进程边界必须清晰、退出信号必须可收敛。
