std::barrier构造时必须严格指定与实际参与线程数一致的phase_count，否则会永久阻塞；应优先使用arrive_and_wait()原子操作，回调在所有线程抵达后、唤醒前执行且仅一次，对象须确保生命周期覆盖所有线程访问。
std::barrier 构造时必须指定线程数，否则无法启动同步
构造 std::barrier 时传入的 phase_count 是“每阶段期望到达的线程总数”，它不是最大线程数，而是当前同步点必须凑齐的参与数。如果实际调用 arrive_and_wait() 的线程少于该值，所有线程会永久阻塞——没有超时、无异常、不报错，只卡死。
常见错误是误用动态线程池：比如启动了 5 个线程，但 std::barrier sync_point(8)；或者某线程因异常提前退出，未执行 arrive_and_wait()，导致其余线程永远等待。
- 务必确保构造参数与实际参与线程数严格一致（调试期可用
assert校验） - 若线程数可能变化，优先用
arrive_and_drop()主动退出同步，而非依赖异常路径 - 不要在循环外构造 barrier 后复用到不同规模的线程组——重用只适用于“同一批线程重复进入同一同步点”
arrive_and_wait() 和 arrive() + wait() 的行为差异很关键
arrive_and_wait() 是原子操作：它先递减计数，再立即阻塞等待阶段完成；而分开调用 arrive() 和 wait() 允许中间插入非同步逻辑，但必须配对使用且保证每个 arrive() 对应一次 wait()（或由其他线程代为触发完成）。
典型误用场景：在 worker 线程中调用 arrive() 后去做耗时 I/O，再调用 wait() —— 这会导致该线程虽已“抵达”，却不参与后续阶段的等待，破坏同步节奏，甚至引发计数错乱。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 绝大多数场景直接用
arrive_and_wait()，语义清晰、不易出错 - 仅当需要“抵达即释放 CPU 做其他事，稍后再同步”时才拆开，且需确保
wait()调用前屏障尚未被其他线程触发完成 -
arrive()返回的arrival_token必须 move 传给wait()，拷贝会编译失败
阶段回调函数（completion function）会在所有线程解除阻塞前执行
构造 std::barrier 时传入的可调用对象（如 lambda），会在计数归零、所有等待线程即将被唤醒的**瞬间**执行，且只执行一次/每阶段一次。这个时机非常特殊：它发生在任何线程从 wait() 返回之前，但所有线程都已确认抵达。
这意味着你可以安全地在回调里更新全局状态、刷新缓存、记录日志，而不用担心竞态——因为此时没有线程还在执行临界区逻辑，也没有线程已开始下一阶段。
- 回调内禁止调用
arrive_and_wait()或任何可能再次阻塞的操作 - 回调抛异常会导致调用
std::terminate()，所以务必用try/catch包裹可能失败的操作 - 若不需要回调，直接用默认构造：
std::barrier sync_point(N)，无需传空 lambda
和 std::latch 混用容易踩内存生命周期坑
std::barrier 可重用，std::latch 一次性；但两者都不能跨线程持有引用。常见错误是把 barrier 对象放在栈上，然后在线程中通过指针或引用访问——主线程函数返回后，栈对象销毁，子线程继续调用 arrive_and_wait() 就是野指针访问。
尤其在 lambda 捕获时：写 [&sync_point]{ sync_point.arrive_and_wait(); } 很危险，除非你能 100% 确保 sync_point 的生存期覆盖所有线程执行完。
- 多线程共享的
std::barrier必须堆分配或定义为 static / 全局对象 - 若用智能指针管理，注意
std::shared_ptr的线程安全仅限于控制块，对象本身仍需外部同步（不过 barrier 成员函数本身是线程安全的） - 测试阶段建议加 ASan/TSan 编译，能快速捕获这类 use-after-free
arrive_and_wait() 调用点的聚合行为，不保证各线程在该点之后的执行顺序或速度一致性。别指望它能替代 mutex 去保护共享数据读写。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
