fetch_add不能直接赋值是因为它返回旧值，x = x.fetch_add(1)会使x变为旧值而非新值；正确用法是忽略返回值或显式计算新值，如int new_val = old_val + 1。
fetch_add 为什么不能直接赋值
因为 fetch_add 返回的是修改前的值，不是新值。写成 x = x.fetch_add(1) 看似顺手，实际会让 x 变成旧值，逻辑全乱。这是初学者最常踩的坑——把原子操作当成普通自增用了。
- 正确做法是：如果要获取新值，得自己加，比如
int new_val = old_val + 1 - 如果只是想“加1并继续用”，通常根本不需要接返回值：
counter.fetch_add(1, std::memory_order_relaxed); - 只有在需要原子地读-改-用（比如实现计数器分配）时，才依赖返回值：
int id = counter.fetch_add(1); // id 是旧值，相当于先取再加
memory_order 参数选哪个才不掉性能又不崩
默认是 std::memory_order_seq_cst，安全但可能拖慢。多数场景其实不需要最强一致性。
- 单线程更新、多线程只读计数器（如日志条目号）：用
std::memory_order_relaxed足够，编译器不会乱序，CPU 也不会额外同步 - 需要和其它内存操作建立 happens-before 关系（比如加完计数后发信号）：至少用
std::memory_order_acquire或std::memory_order_release配合 - 跨线程依赖某个变量的值（比如等计数到 10 才启动下一步）：必须用
std::memory_order_acquire去 load，否则可能看到陈旧值
和 ++x、x++ 的行为差异在哪
std::atomic<int>::fetch_add</int> 是明确的原子读-改-写；而 ++x 对 std::atomic 类型其实是调用了 fetch_add(1) + 1 的封装，返回新值；x++ 则返回旧值 —— 但底层都走 fetch_add，语义不同只在返回值。
-
x.fetch_add(1)→ 返回旧值（等价于x++） -
++x→ 返回新值（内部是fetch_add(1) + 1） - 直接写
x += 1也调用fetch_add，但返回 void，更接近语义本意 - 别混用：对同一变量交替用
fetch_add和++x没问题，但若和非原子访问共存，就彻底失去原子性保障
整数溢出时 fetch_add 怎么办
std::atomic<int>::fetch_add</int> 不检查溢出，行为和内置整数一样：有符号溢出是未定义行为（UB），无符号是回绕（well-defined）。这点极易被忽略。
- 用
int时，如果可能溢出，必须自己判断：if (counter.load() - 用
unsigned int或uint64_t更稳妥，溢出即回绕，适合循环 ID、ring buffer 索引等场景 - Clang/GCC 的
__builtin_add_overflow无法直接用于std::atomic，得先load()再算，但这中间有竞态 —— 所以真要防溢出，得用compare_exchange_weak循环重试
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
