seq_cst是必须用的：当多线程通过不同原子变量跨变量协调且依赖严格全局顺序时，如标志位与数据分离的生产者-消费者场景，仅acquire/release无法保证“标志先于数据”的跨变量顺序，必须成对使用seq_cst才能避免读到未初始化数据。
什么时候 seq_cst 不是可选项，而是必须用？
当多个线程通过不同原子变量进行“跨变量协调”，且逻辑上依赖严格的全局顺序时，seq_cst 是唯一能保证正确性的选择。不是性能差就换别的——换掉就可能出错。
典型场景：一个线程写入数据后设置标志位，另一个线程先检查标志再读数据，但标志和数据是两个独立的 std::atomic 变量。此时若标志用 memory_order_relaxed 或 acquire/release，编译器或 CPU 可能重排读写，导致读到未初始化的数据。
- 必须用
seq_cst的组合：写数据 + 写标志（都用seq_cst），读标志 + 读数据（也都用seq_cst） -
acquire/release能保证单个同步点的配对，但无法约束“标志 A 先于数据 B”这种跨变量的先后关系 - 哪怕只有一处用了
seq_cst，整个程序的seq_cst操作仍构成一个单一全序，这是其他模型不具备的性质
seq_cst 和 acquire/release 在实际代码里差在哪？
差别不在语法，而在对重排序的约束粒度。一个 store(memory_order_release) 只禁止其前面的读写乱序到它之后；而 store(memory_order_seq_cst) 还额外要求：所有线程看到这个 store 的时间，在全局时钟意义上必须一致。
这意味着：如果线程 1 执行 a.store(1, seq_cst) 后线程 2 看到 a == 1，那么线程 3 之后看到 a == 1 时，也一定能观察到线程 1 在该 store 之前做的所有内存操作（即使线程 3 没和线程 1 直接同步）。
立即学习“C++免费学习笔记（深入）”；
-
acquire/release是“点对点”同步：A release → B acquire，仅在这两条指令之间建传递性 -
seq_cst是“全网广播”式同步：任意两个seq_cst操作之间自动形成偏序，无需显式配对 - 常见误判：以为只要没用
relaxed就安全——其实acquire/release在三方协作时可能漏掉关键顺序
哪些错误现象会暴露你本该用 seq_cst 却没用？
不是崩溃，也不是断言失败，而是偶发、难以复现、加日志就消失的逻辑错误。比如：
- 生产者设置了
ready_flag，消费者读到true却发现data仍是初始值（零值或垃圾值） - 两个线程交替执行某协议，第三线程观察到违反协议的状态（如“已提交但未开始”）
- 在 ARM/AArch64 或 RISC-V 上问题更频繁——x86 的强内存模型会掩盖部分错误，但不等于正确
- GCC/Clang 开启
-O2后问题加剧：编译器基于宽松内存序假设做激进重排
这类问题不会报 segmentation fault，也不会触发 TSAN（ThreadSanitizer）警告——因为从语言标准看，你的代码“合法”，只是语义不符合预期。
能不能只在关键位置补一个 seq_cst 就解决问题？
不能。内存序是成对起作用的，单边升级无效。比如只把 store 改成 seq_cst，load 还是 acquire，那 load 仍然可能被重排到 store 前，或者看到过期值。
- 必须成对修改：写端和读端涉及同一逻辑依赖的原子操作，都要用
seq_cst - 混用风险高：一个
seq_cststore 和一个relaxedload 组合，等价于完全无序 - 别指望编译器“帮你推断”——C++ 标准不定义隐式升级，
std::atomic的 memory order 是显式契约
真正难的不是写对那一行 seq_cst，而是识别出哪几个变量、哪几条路径之间存在隐含的全局顺序依赖。这种依赖往往藏在业务逻辑里，而不是同步原语里。
