Go 中需手动管理 HTTP Server、数据库连接池、goroutine 等底层资源生命周期，必须显式调用 Shutdown()、db.Close() 和第三方 Close() 方法，并配合 context 与信号处理实现优雅退出，避免资源泄漏和请求中断。
Go 框架本身没有统一的“生命周期管理”抽象——它不像 Spring 或 Laravel 那样内置启动、运行、关闭钩子。真正需要你手动管理生命周期的，是框架所依赖的底层资源：HTTP server、数据库连接池、消息通道、定时任务、后台 goroutine。搞不清这点，容易在 main 函数末尾直接退出，导致连接未释放、channel 未关闭、goroutine 泄漏。
HTTP Server 的启停必须显式控制
标准库 http.Server 启动后会阻塞，但没有内置优雅关闭机制。直接调用 os.Exit() 或让 main 返回，会导致正在处理的请求被粗暴中断、连接未清理、TLS session 未终止。
- 必须用
server.Shutdown()配合context.WithTimeout()，给正在处理的请求留出完成时间 - 监听
os.Interrupt或syscall.SIGTERM信号，触发关闭流程，不能只靠 Ctrl+C 默认行为 -
Shutdown()会等待所有活跃连接关闭，但不会等 background goroutine；如果你在 handler 里起了 goroutine，得自己加 cancel 控制
示例关键片段：
srv := &http.Server{Addr: ":8080", Handler: mux}
go func() { log.Fatal(srv.ListenAndServe()) }()
// 收到信号后
sig := make(chan os.Signal, 1)
signal.Notify(sig, os.Interrupt, syscall.SIGTERM)
<-sig
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
srv.Shutdown(ctx) // 不会 panic，即使没在运行
database/sql 连接池不是“开箱即用”的自动管理
sql.DB 是连接池句柄，它本身不持有连接，也不自动关闭底层连接。它的生命周期应与应用生命周期对齐，而不是按需创建/销毁。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
立即学习“go语言免费学习笔记（深入）”；
- 不要在每个 handler 里
sql.Open()—— 这会泄漏连接池，且无法复用连接 - 全局单例或注入式初始化一次即可，关闭时调用
db.Close()，它会等待所有已借出连接归还后才真正关闭 -
db.SetConnMaxLifetime()和db.SetMaxIdleConns()必须设，否则空闲连接可能长期滞留，尤其在云环境 NAT 超时后变成僵死连接
goroutine + channel 组合最容易泄漏
很多框架封装了 “background job” 或 “event listener”，背后其实是起 goroutine 监听 channel。一旦 channel 未关闭、接收端未退出，该 goroutine 就永远阻塞，且引用 channel 导致 GC 无法回收。
- 永远不要只写
for range ch而不配合ctx.Done()—— 如果 sender 忘记close(ch)，receiver 就卡死 - 用
select包裹接收逻辑：case msg := <-ch:+case <-ctx.Done(): return - 如果 channel 是用于 goroutine 间通信（非事件广播），建议用无缓冲 channel + 显式
close()，避免 sender 发送时 panic
第三方 SDK（如 Redis、gRPC client）常忽略 Close 方法
像 redis.UniversalClient、grpc.ClientConn 这类对象，内部维护连接池和 background goroutine。它们的 Close() 方法不是可选的，而是必须调用的退出步骤。
- 不调
client.Close()→ 连接保持打开 → TCP TIME_WAIT 堆积 → 端口耗尽 - 不调
conn.Close()→ gRPC 内部 keepalive goroutine 不退出 → 内存缓慢增长 - 推荐做法：把所有要 close 的资源注册到一个
sync.WaitGroup或自定义Closer接口，在 shutdown 流程中统一调用
最常被跳过的，是认为 “反正进程要退出了，OS 会回收一切”。但在容器环境、热更新、测试场景下，这个假设不成立；更隐蔽的问题是，未关闭的资源会拖慢 Shutdown() 超时判断，让服务看起来“假死”。
