不能在 init 或 main 中硬启 goroutine 定时清理，因其无法关闭、测试泄漏、启动过早、信号不可控、sleep 误差大；正确做法是封装带 Start/Stop 的结构体，用 ticker 和 done channel 控制生命周期。
直接起一个 go func() 配合 time.Sleep 做定时清理，基本等于给服务埋雷——停不掉、测不了、读性能被拖垮、还可能漏删或 panic。
为什么不能在 init 或 main 里硬启 goroutine
常见错误是写成这样：
func init() {
go func() {
for {
time.Sleep(30 * time.Second)
cleanupCache()
}
}()
}问题很实在：
- 测试时无法关闭这个 goroutine，
go test结束后它还在跑，导致资源泄漏甚至 panic - 服务还没监听 HTTP 端口，缓存 map 还是空的，就开始扫，白占 CPU
- 进程收到
SIGTERM时无法通知它退出，强行 kill 可能导致清理中途断掉 -
time.Sleep会累积误差，连续 10 次调度就可能偏移 200ms 以上
正确封装：带 Start/Stop 的清理器结构体
必须把清理逻辑收进一个可控制的结构体里，核心是 done chan struct{} 和 time.Ticker：
立即学习“go语言免费学习笔记（深入）”；
- 启动时机放在
http.ListenAndServe成功之后，或 gRPC server 启动完成回调中 - 停止时机在收到关闭信号后、调用
server.GracefulStop()前 -
Start()内部用select监听ticker.C和c.done，一收到done就退出循环 -
Stop()要先 closec.done，再调ticker.Stop()，顺序不能反
清理函数里最容易踩的三个坑
哪怕结构体封装对了，清理逻辑本身也常翻车：
-
别用
for range map删除元素：Go map 迭代时删 key 会触发迭代器失效，行为未定义。改用「手动采样」：keys := make([]string, 0, 100); for k := range cacheMap { keys = append(keys, k); if len(keys) >= 100 { break } } -
过期判断必须基于单次
time.Now()快照：写成if time.Since(item.ExpireAt) > 0是错的；正确是开头now := time.Now()，后面统一用now.After(item.ExpireAt) -
读多写少必须用
sync.RWMutex：所有Get走RUnlock()，清理函数用Lock()；用sync.Mutex会让上万 QPS 的读请求排队等几毫秒的清理，延迟毛刺明显
文件缓存和数据库清理要额外注意什么
如果是清理磁盘文件或 DB 记录，规则更硬：
- 文件清理不能在
filepath.WalkDir回调里直接os.Remove——某个文件正被其他 goroutine 打开读取时会失败，且错误不处理会导致整个遍历中断。应分两步：先收集路径列表，再逐个os.Remove并用if err != nil && !os.IsNotExist(err)过滤非关键错误 - 数据库
DELETE必须带LIMIT，例如 MySQL 写DELETE FROM logs WHERE created_at ；没索引的 <code>WHERE字段会全表扫描，一次清理就卡住连接池 - 别依赖文件系统
mtime判断过期——容器挂载、NFS、touch 修改都可能污染它。写文件时同步写一个.meta文件，里面只存纳秒级过期时间戳
真正难的不是“怎么启 goroutine”，而是清理节奏和粒度的平衡：间隔太短（500ms）或单次扫太多（全量 range），都会让 GC 和锁竞争突然恶化；但间隔太长（1h）又导致内存虚高。实际压测时，10s 间隔 + 每次 100 条，往往是多数服务最稳的起点。
