WaitGroup 的 state1 字段通过位运算拆分为高32位waiter和低32位counter：counter = int32(state & 0xffffffff)，waiter = int32(state >> 32)，所有操作均基于单个uint64原子变量，依赖64位对齐保障原子性。
WaitGroup 的 state1 字段怎么拆成高低 32 位？
WaitGroup 的核心状态全压在 state1 这个 uint64 字段里：高 32 位是等待者计数（cwait），低 32 位是活动任务计数（counter）。这不是 Go 语言层面的“结构体字段”，而是通过位运算硬拆出来的。
实际读取时，Go 运行时用原子操作 atomic.LoadUint64 一次性读出整个 state1，再用位掩码提取：
counter := int32(state & 0xffffffff) // 低32位 waiters := int32(state >> 32) // 高32位
这个设计直接规避了对两个独立字段做两次原子操作的开销，也避免了竞态——但代价是必须严格保证 state1 在内存中 64 位对齐（否则 32 位平台会 fallback 到 [3]uint32 数组布局）。
为什么 WaitGroup 不能值传递？
因为 noCopy 字段和 state1 共享内存布局。一旦值拷贝，两个 WaitGroup 实例就各自拥有独立的 state1，Done() 调在副本上，主 goroutine 的 Wait() 永远等不到归零。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：
- 程序卡在
wg.Wait()不返回，CPU 占用极低（不是忙等，是真的挂起） -
go vet报错：assignment copies lock value to wg2: sync.WaitGroup contains sync.noCopy
正确做法始终传指针：go worker(&wg)，而不是 go worker(wg) 或 go worker(*wg)。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
Add 和 Done 的调用顺序与负数风险
Add(delta) 允许负数，Done() 就是 Add(-1) 的封装。但负数本身不危险，危险的是「在 Wait() 已开始后调用 Add()」。
原因：Wait() 会先将等待者计数 +1，再检查 counter 是否为 0；如果此时另一个 goroutine 调用 Add(n)，而 n 是正数，就会让 counter 变成正数，但等待者计数已增加——这会导致后续 Done() 无法唤醒所有等待者，甚至永久阻塞。
安全前提只有两个：
-
Add()必须在任何Wait()调用之前完成（最稳妥） - 或确保
Add()和Wait()不并发执行（需额外同步，不推荐）
典型反例：wg.Add(1) 放在 goroutine 内部、且该 goroutine 启动后才调 wg.Wait() —— 这几乎必然导致死锁。
WaitGroup 的唤醒机制依赖 runtime_Semacquire/semarelease
Wait() 阻塞时，并不是轮询或自旋，而是调用 runtime_Semacquire(&wg.sema)，把当前 goroutine 挂起并加入 Go 调度器的等待队列；Done() 在发现 counter 归零且有等待者时，调用 runtime_Semrelease(&wg.sema) 唤醒一个 goroutine。
这个信号量不是用户态实现，而是 runtime 层的底层设施，和 chan、mutex 共享同一套 park/unpark 逻辑。因此它具备：
- 真正的 OS 级挂起（不占 CPU）
- 可被抢占（不会因长时间等待阻塞调度器）
- 无虚假唤醒（不像 POSIX condition variable）
但这也意味着：一旦 WaitGroup 被误用（如重复 Done() 导致 counter 变负），runtime_Semrelease 可能被多次调用，而 Go 运行时对此没有校验——结果就是信号量被透支，后续 Wait() 可能立即返回，造成逻辑错乱。
