gin 本身不提供平滑重启能力，必须靠外部信号监听 + http.server.shutdown 配合实现；热更新需借助 realize 等工具，但其已多年未维护，存在 go.mod 兼容性问题。
直接上结论：Gin 本身不提供平滑重启能力，必须靠外部信号监听 + http.Server.Shutdown 配合实现；热更新（改代码自动重启）则需借助第三方工具如 realize，但要注意其已多年未维护，go.mod 兼容性问题频发。
用 http.Server.Shutdown 实现真正的平滑关闭
Go 1.8+ 的 http.Server 提供了 Shutdown 方法，它会等待活跃连接处理完再退出，这才是“平滑”的核心。关键不是“重启”，而是“先关旧、再启新”——这需要你手动管理生命周期。
常见错误现象：ctrl+c 或 kill -15 后请求直接中断，日志里看到 read: connection reset by peer；或者 srv.ListenAndServe() 被阻塞，导致信号根本收不到。
实操要点：
- 不能直接调用
router.Run()，必须显式构造*http.Server，并把router赋给Handler字段 - 启动服务必须用
go srv.ListenAndServe()，否则主线程卡死，无法监听信号 -
Shutdown必须传入带超时的context.Context，比如context.WithTimeout(context.Background(), 10*time.Second)，避免无限等待 - 要监听
syscall.SIGINT和syscall.SIGTERM，Linux systemd、Docker stop 默认发的就是SIGTERM
realize 热更新安装失败：gopkg.in/urfave/cli.v2 报错怎么解
执行 go install github.com/oxequa/realize 时出现 parsing go.mod: module declares its path as: github.com/urfave/cli/v2 but was required as: gopkg.in/urfave/cli.v2，本质是 Go 模块路径重定向冲突。
这不是 realize 独有，而是早期 Go 生态中 gopkg.in 和 github.com 双源共存遗留的问题。官方早已弃用 gopkg.in，但 realize 的依赖树里还硬编码着它。
解决方式唯一且必须：在项目根目录的 go.mod 中加 replace 规则：
replace gopkg.in/urfave/cli.v2 => github.com/urfave/cli/v2 v2.2.0
注意三点：
- 该
replace必须写在你自己的项目go.mod里，不是 realize 源码里 —— 因为你用的是go install，它会拉取 realize 的模块，而你的项目只是“使用者” - 版本号要严格匹配报错信息里的
v2.2.0，不能写latest或省略 - 加完后需运行
go mod tidy，否则realize启动时仍可能因缓存加载旧路径失败
别把热更新（realize）和平滑重启（Shutdown）混为一谈
这是最容易被忽略的混淆点：realize 修改代码后杀掉旧进程、拉起新进程，整个过程没有共享 socket、没有父子进程协作，旧连接会被强制断开 —— 它不是平滑重启，只是开发期便利工具。
生产环境必须用另一套机制：比如 endless（已归档但稳定）、facebookarchive/grace（更底层），或自己基于 fork + SO_REUSEPORT 实现。它们的共同点是：新进程继承监听 fd，旧进程等请求自然结束。
如果你在 Docker 中跑 Gin，还要额外注意：
- Docker 默认只转发
SIGTERM给 PID 1 进程，若你没用exec启动 Gin（比如写了sh -c "go run main.go"），信号根本到不了你的 Go 程序 - 务必在
Dockerfile中用ENTRYPOINT ["./your-binary"]，而非shell形式 - Kubernetes 的
terminationGracePeriodSeconds必须 ≥ 你Shutdown设置的 context 超时，否则 Pod 在 Shutdown 完成前就被强杀
真正难的从来不是写几行 Shutdown 代码，而是厘清“开发热更”和“生产平滑”是两套完全不同的机制，且后者涉及进程模型、信号传递、容器调度多个层面的对齐。
