waitgroup 计数器不会因数值过大溢出，是因为运行时对高32位counter做有符号整数检查，add负值或done超限会立即panic；它本质是严格配对的加减器，add与done次数不等即崩溃。
WaitGroup 的计数器不会因“数值太大”而溢出，但会因负值立即 panic；它不是循环计数器，而是严格配对的整数加减器——只要 Add() 和 Done() 次数不等，就会崩。
为什么 WaitGroup 计数器不会整数溢出
WaitGroup.state 高 32 位存 counter，是带符号语义的 int32（虽用 uint64 存储，但 runtime 按有符号整数做减法检查）。Go 运行时只在 Add(-1) 后检查是否 sync: negative WaitGroup counter。它根本不管“正向加到 2^31-1 会不会绕回”，因为：
- 实际业务中几乎不可能调用 Add(2147483647) 次；
- 即使真加到 0x7fffffff，下一次 Add(1) 会变成 0x80000000 —— 此时高 32 位解释为负数，panic 立刻触发；
- 所以“溢出”在这里不是 silent wraparound，而是显式失败。
Add 参数过大不是问题，配平错误才是
-
Add(n)的n可以是任意 int，包括大正数（如wg.Add(1000000)），只要后续Done()总次数等于它，就不会出错 - 真正危险的是：漏调
Done()（导致Wait()永远阻塞）、多调Done()（立刻 panic）、或在Wait()执行中并发调Add()（panic：Add called concurrently with Wait） - 常见误判：“我加了 100 万次，是不是快溢出了？”——其实你只是在等 100 万个
Done()，只要它们全执行，就安全
WaitGroup 不适合动态扩缩容场景
它设计目标是“已知任务数的静态等待”，不是运行时动态增减的队列：
- 若从 channel 动态接收任务，不能边收边 Add(1) + go，否则可能 Wait() 提前返回（计数还没加完）或竞态 panic
- 正确做法：先 collect 所有任务，再统一 wg.Add(len(tasks))，然后启动 goroutine
- 如果必须流式处理，改用 channel + atomic.Int64 自定义计数器，或引入 worker pool + context 控制生命周期
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
32 位系统上真正的“溢出相关”风险是内存对齐
这不是数值溢出，而是硬件级崩溃：
- 在 GOARCH=386 下，atomic.AddUint64 要求 8 字节对齐，否则 SIGBUS
- sync.WaitGroup 内部通过 state1 [3]uint32 模拟对齐，但若实例分配在非 8 字节边界（如逃逸到堆后被 GC 搬运到 4 字节对齐地址），仍可能 crash
- 唯一可靠方案：只在栈上声明（wg := sync.WaitGroup{}），或用 new(sync.WaitGroup) —— Go runtime 保证 new 分配的首个字段 64-bit aligned
WaitGroup 的“同步逻辑”本质是手动维护一个跨 goroutine 的整数契约：你承诺加多少，就必须减多少；它不帮你记账，也不替你兜底。最容易被忽略的，不是大数，而是那个看似无害的 defer wg.Done() 被包在闭包里、或藏在 return 语句后面没执行。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
