Go模块本身不释放资源，真正需管控的是初始化时创建的全局状态、连接池、缓存和goroutine；常见冷启动慢、内存不降的主因是在init()或包级变量中执行重操作，如预热HTTP客户端、加载大配置、启动后台goroutine。
无服务器环境里，Go 模块本身不“释放资源”——真正要管的是模块初始化时创建的全局状态、连接池、缓存和 goroutine。模块只是代码组织单元，资源生命周期由你写的初始化逻辑决定。
为什么 go mod init 后服务冷启动仍慢、内存不降
模块加载本身开销极小，但常见陷阱是：在init()或包级变量初始化时做了重操作，比如预热 HTTP 客户端、加载大配置、启动后台 goroutine。这些一旦执行，就脱离模块边界，持续占用资源。
- 检查所有
init()函数：是否调用了http.DefaultClient.Do()、sql.Open()、sync.Pool{New: ...}等？它们会在首次导入包时立即执行 - 避免包级变量直接持有可能长期存活的对象，例如：
var db *sql.DB = sql.Open(...)—— 改为函数内按需获取或显式初始化 - 用
go tool trace抓冷启动阶段的 goroutine 创建点，定位非预期的后台任务
HTTP 客户端连接池必须按请求生命周期回收
Serverless 场景下，函数实例可能被复用多次，但每次调用应视为独立上下文。若复用全局http.Client且未限制连接池，IdleConnTimeout 会累积空闲连接，最终耗尽 fd 或触发 timeout waiting for connection。
- 不要用
http.DefaultClient：它默认不限制连接数，且IdleConnTimeout为 0 - 每个 handler 内创建轻量
http.Client（可复用 Transport），并显式设MaxIdleConns = 2、MaxIdleConnsPerHost = 2、IdleConnTimeout = 5 * time.Second - 务必在 handler 结尾调用
resp.Body.Close()，否则底层连接无法进入 idle 状态，更不会被超时清理 - 如果调用频次极低（如每分钟一次），干脆设
Transport.MaxIdleConns = 0，绕过连接池，避免残留
sync.Pool 对象归还必须重置长度，否则内存不释放
Serverless 实例复用时，sync.Pool里缓存的对象会被反复 Get/Put。若 Put 前没清空内容，旧数据引用会阻止 GC，导致内存只增不减。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
bufPool.Put(buf)—— buf 是原 slice，底层数组仍被持有 - 正确写法：
bufPool.Put(buf[:0])—— 截断长度为 0，切断对原数据的引用 - Pool 的
New函数返回对象不能含外部状态（如文件句柄、网络连接），否则 Put 后下次 Get 可能 panic - 高频分配小 buffer（如 JSON 解析）适合 Pool；大对象（>1MB）或带 finalizer 的对象不适合，GC 压力反而更大
GOMEMLIMIT 必须与函数内存配额对齐，否则 OOM 不可预测
无服务器平台（如 AWS Lambda、Cloudflare Workers）给函数分配固定内存，但 Go runtime 默认无视该限制，直到 cgroup kill 才终止——此时已无机会优雅释放。
- 设
GOMEMLIMIT为平台内存配额的 80%～90%，单位必须是字节（例如 2Gi 配额 →GOMEMLIMIT=1717986918） - 不能靠 Go 1.22+ 的自动推导：它只读
/sys/fs/cgroup/memory.max，而部分平台（如早期 Cloudflare）不暴露该路径 - 验证方式：函数启动后打印
runtime/debug.ReadMemStats().HeapSys，应稳定在 GOMEMLIMIT 附近，而非一路涨到配额上限 - 若平台不支持环境变量注入（如某些边缘 runtime），只能改用
runtime/debug.SetMemoryLimit()（Go 1.22+），但必须在main()最开头调用
真正难的不是写模块，而是让每个模块的初始化和清理行为可预测、可中断、可计量。Serverless 下没有“程序退出”这个安全兜底，所有资源释放都得在 handler 返回前完成——哪怕只是把一个 slice 置为 nil，也可能决定这次调用会不会触发 OOM。
