零停机发布本质是平滑重启，非go语言特性：新进程通过文件描述符继承复用旧进程监听socket，旧进程调用http.server.shutdown()等待活跃连接结束后退出，需避免直接kill或os.exit导致rst中断。
零停机发布不是靠 Go 本身实现的
Go 编译出的是静态二进制，没有运行时类加载机制，go run 或 go build 后启动新进程，必然伴随老进程退出 —— 这就是连接中断、goroutine 丢失、事务未完成的根本原因。所谓“热升级”，实际是外部工具或自研逻辑控制的**平滑重启**，核心在于：新进程接管监听 socket，老进程等活跃连接自然结束后再退出。
用 endless 实现 TCP 层级的 socket 复用
标准库 http.Server.Shutdown() 能优雅关闭，但无法复用监听套接字，新进程仍要重新 bind/listen，内核连接队列（net.core.somaxconn）里的待处理请求会丢。而 endless 的关键能力是：通过 fork + exec 让子进程继承父进程的 listener 文件描述符，新二进制直接从已有 socket 接收连接，旧进程在无活跃连接后退出。
- 只适用于 Linux，Windows 不支持 fork 和文件描述符继承
- 需确保新旧二进制兼容：HTTP 路由、中间件行为一致，否则并发请求可能路由错乱
- 编译时必须开启
-ldflags="-s -w"减小体积，避免升级包过大拖慢部署 - 启动命令不能带
--分隔符，否则endless无法正确解析参数传递给新进程
air 和 gin 的 live reload 只适合开发
这类工具本质是监听 .go 文件变化，触发 go build + exec.Command 启动新进程，老进程不感知也不协作 —— 没有 socket 复用，没有连接等待，HTTP 请求直接 502/EOF。它解决的是本地调试反馈速度问题，不是生产零停机。
-
air的.air.toml中kill_delay设再大，也无法让老进程等待 HTTP 连接完成 -
gin的gin.Run()封装只是简化开发启动，底层仍是http.ListenAndServe，无 graceful 控制 - IDE 保存临时文件（如
main.go~）可能反复触发重建，导致进程堆积 - 无法透传原进程的
SIGUSR2、环境变量（如DB_URL），需手动在配置里写死
生产打包必须分离构建与运行时依赖
零停机更新要求新二进制能立即启动并接管流量，因此构建产物必须纯净：不含 go 工具链、不依赖 GOPATH、不硬编码开发路径。Docker 镜像应采用多阶段构建，最终镜像只含可执行文件和必要配置。
- 禁止在 Dockerfile 中
COPY . .后直接go run，这会让镜像带上源码和模块缓存，体积膨胀且不安全 - 使用
CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"'生成纯静态二进制，避免容器中缺失 libc - 配置文件（如
config.yaml）不应打入镜像，应通过 ConfigMap 或环境变量注入，否则每次配置变更都要重打包 - 升级包命名建议含 commit hash 和时间戳，例如
service-v1.2.0-20260722-abc123，便于回滚定位
真正难的不是编译出一个新二进制，而是让新旧两个进程在内核层面协同交接 socket，同时保证中间件、数据库连接池、WebSocket 注册表这些状态不被撕裂 —— 这些细节不会出现在任何 go build 命令里，得靠代码里显式控制生命周期。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
