Wait方法能阻塞而不死锁，是因为它原子地释放锁并挂起线程，进入WAITING/TIMED_WAITING状态，不占用CPU且允许其他线程获取锁调用notify；唤醒后需循环检查条件是否真正满足，避免虚假唤醒。
Wait 方法为什么能阻塞而不死锁
Wait 不是靠轮询或 for {} 空转实现阻塞的，它底层调用的是 Go 运行时的信号量原语 runtime_Semacquire。当计数器非零时，Wait 会原子地将“等待者计数”（state 的低 32 位）加 1，然后挂起当前 goroutine，交出调度权——这和 select {} 或 time.Sleep 的挂起机制本质一致，但更轻量、无时间开销。
关键点在于：只有 Done（或 Add(-1)）真正把高 32 位计数器减到 0 时，才会触发一次 runtime_Semrelease，唤醒所有在 sema 上等待的 goroutine。唤醒不是逐个通知，而是批量释放信号量，所以多个 Wait 调用可被同时解除阻塞。
Wait 阻塞时 state 字段发生了什么变化
WaitGroup.state 是一个 uint64 原子变量，被拆成两部分：
- 高 32 位：运行中待完成的 goroutine 数（即你通过
Add设置、Done消耗的值） - 低 32 位：当前有多少个 goroutine 正在调用
Wait并处于阻塞状态
当你第一次调用 Wait 且计数器 > 0 时，Wait 会尝试用 atomic.CompareAndSwapUint64 把低 32 位 +1；如果此时高 32 位恰好归零，就直接返回，不进等待队列。
注意：state 是单个字段，两个部分共享同一内存地址，因此所有操作都必须原子，不能拆成两次读写，否则会破坏一致性。
Wait 被唤醒后为什么还要检查 state
唤醒只是「通知可能可以继续」，不是「保证可以继续」。因为：
- 多个
Done可能在唤醒前已执行，导致计数器提前归零 - 有竞争：A goroutine 在唤醒瞬间被调度，但 B goroutine 紧接着又调用了
Add(1)，计数器又变非零 - Go 调度器不保证唤醒与原子读写的严格时序
所以 Wait 在从 runtime_Semacquire 返回后，会再次读取 state，提取高 32 位判断是否真为 0。若仍非零，就继续等待；若为 0，才真正退出。
这也是为什么源码里 Wait 是个 for 循环，而不是一次判断就完事。
Wait 阻塞期间 panic("sync: WaitGroup misuse") 怎么触发
这个 panic 发生在 Wait 从信号量返回后，发现 *statep != 0，但自己已经走出了等待逻辑——说明有人在 Wait 执行中途修改了 WaitGroup 的状态，最常见的是：
- 在
Wait还没返回时，又调用了一次Add(n)（比如误把Add放在循环里重复调用） -
WaitGroup被复制（如作为函数参数传值、赋值给另一个变量），导致两个副本的state和sema不同步 - 多个 goroutine 同时对同一个
WaitGroup调用Add且 delta 为负，导致计数器绕回或溢出（虽然罕见，但int32计数器上限是 2³²−1）
一旦触发该 panic，说明 WaitGroup 的使用模式已违反其设计契约：Add 必须在所有 Wait 开始前完成，Done 必须与 Add 匹配，且对象不可复制。
