微服务上线需两阶段：先监听不Accept，待初始化完成且健康检查通过后再注册到注册中心并开放Accept；下线时需Shutdown HTTP、反注册、等待goroutine退出，并用atomic计数器监控活跃请求。
golang服务启动时如何注册到注册中心并确保就绪后再接受流量
微服务上线的核心不是“启动成功”，而是“已注册且健康检查通过”。直接在 main() 启动后立刻注册，容易因依赖未就绪（如数据库连接池未填满、缓存预热未完成）导致注册成功但实际不可用。
正确做法是把服务启动拆成两阶段：先启动监听但不对外暴露（如 HTTP server 先监听但不 Accept），等所有初始化完成、健康检查能返回 200 后，再向注册中心（如 Consul、Nacos、etcd）写入服务实例，并开放 Accept。
- 用
http.Server的ListenAndServe配合net.Listener手动控制 Accept：调用net.Listen("tcp", addr)获取 listener，传给&http.Server{...}.Serve(l)，但先不调用Serve - 初始化 DB、Redis、配置加载等逻辑完成后，再调用
server.Serve(l)开始处理请求 - 注册时机必须放在
Serve之前，且注册后需主动触发一次健康检查（如向 Consul 的/v1/agent/check/pass/xxx发 PUT） - 注册失败应 panic 或重试有限次数，不能静默降级——否则服务“看似在线”实则未注册，流量会打丢
golang服务关闭时如何拒绝新请求并等待存量请求完成
直接 os.Exit(0) 或杀掉进程会导致正在处理的 HTTP 请求被中断，TCP 连接 RST，客户端收到 EOF 或超时。优雅下线的关键是：停止接收新连接 + 等待活跃请求自然结束 + 主动注销注册中心。
http.Server.Shutdown() 是标准解法，但它只负责 HTTP 层；若服务还跑着 gRPC、WebSocket 或后台 goroutine（如定时任务、消息消费），需统一协调。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 在收到
SIGTERM或SIGINT后，立即调用server.Shutdown()并传入 context（带超时，如 30s） - 同时调用注册中心 SDK 的反注册接口（如 Consul 的
/v1/agent/service/deregister/xxx），最好加重试和超时（避免注销失败导致“幽灵实例”） - 用
sync.WaitGroup管理所有长期运行的 goroutine：启动时wg.Add(1)，goroutine 结束前wg.Done()；Shutdown 前调用wg.Wait() - 注意：gRPC Server 也需调用
GracefulStop()，不要用Stop()—— 后者会立即断开所有连接
如何判断一个 golang HTTP handler 是否还在处理请求
Go 的 http.Server 没有暴露“当前活跃请求数”的接口，但可通过中间件 + 全局计数器实现粗粒度监控，用于决策是否允许下线。
单纯靠 http.Server.ConnState 不可靠：它回调频繁、状态切换快，且无法区分“已响应完”和“正在写响应体”。更稳妥的方式是在 handler 入口/出口加计数。
- 定义全局
var activeRequests int64，用atomic.AddInt64增减 - 在顶层 middleware 中：进入时
atomic.AddInt64(&activeRequests, 1)，defer 中atomic.AddInt64(&activeRequests, -1) - 提供
/healthz接口，当activeRequests == 0且注册中心注销成功时，才返回200，供负载均衡器做下线探测 - 避免在 handler 内部用锁保护计数器——高并发下锁争用严重；
atomic是零成本方案
为什么用 context.WithTimeout 控制 Shutdown 却还是超时退出
常见错误是只对 server.Shutdown() 本身设 timeout，却忽略了 handler 内部可能存在的阻塞操作（如未设 timeout 的 DB 查询、HTTP 调用、channel receive）。这时 Shutdown 会等满整个 timeout，然后强制终止，导致请求被截断。
根本解法是让每个可能阻塞的操作都受同一 context 控制，而非仅依赖 Shutdown 的顶层 timeout。
- HTTP handler 中，所有外部调用（
db.QueryContext、http.Client.Do(req.WithContext(ctx))）必须传入 handler 的ctx，而非context.Background() - 使用
context.WithTimeout(r.Context(), 5*time.Second)为每个请求单独设 deadline，比全局 Shutdown timeout 更精细 - 后台 goroutine（如消息消费者）启动时应接收一个
ctx，并在select { case 中监听退出信号 - 检查日志中是否有
context deadline exceeded，它是 handler 未正确传播 context 的明确信号
