直接用 std::atomic 操作指针易出错，因标准不保证其 lock-free；节点须 trivially copyable、无虚函数/引用/非平凡析构；需运行时检查 is_lock_free()，防范 aba、内存序错误及节点复用风险。
为什么直接用 std::atomic 操作指针会出错？
因为 c++ 标准不保证 std::atomic<t></t> 对任意自定义类型 T 的 CAS 操作是 lock-free 的，尤其当 T 含有非平凡析构函数或对齐要求时，is_lock_free() 很可能返回 false。底层可能退化为互斥锁模拟，彻底失去无锁意义。
- 务必在运行时检查：
stack_head.is_lock_free()，不能只看编译期std::atomic<t>::is_always_lock_free</t> - 节点必须是 trivially copyable，且避免虚函数、引用、非平凡构造/析构——否则原子操作行为未定义
- 典型翻车点：在节点里放
std::String或std::vector，哪怕只是临时测试，也会让compare_exchange_weak静默失效
compare_exchange_weak 循环里为什么总要重读 head？
不是为了“更新变量”，而是因为 ABA 问题下，head 地址虽未变，但指向的对象可能已被释放又重用。CAS 成功只说明地址没被别人改过，不代表节点仍有效；循环开头重读，是配合后续的内存序与释放策略做安全判断。
- 标准写法是把读 head 放在循环最外层，而不是只在 CAS 失败后读——否则漏掉并发 pop 导致的 head 变更
- 必须搭配
memory_order_acquire（pop）和memory_order_release（push），否则编译器/CPU 乱序会让其他线程看到节点成员未初始化的状态 - 别用
compare_exchange_strong替代：它在弱一致性平台上可能死循环，而 weak 的 spurious failure 正是用来规避总线争抢的
如何安全地复用已弹出的节点？
无锁栈里节点不能直接 delete，否则其他线程可能正用着旧指针。常见做法是延迟回收，但实现方式直接影响正确性。
- 最简方案：用
std::shared_ptr包裹节点，push/pop 全用原子智能指针——但注意std::atomic<:shared_ptr></:shared_ptr>在 C++20 前不是标准支持，且引用计数本身有锁开销 - 实用折中：自己维护一个 per-Thread 的本地回收链表，配合 epoch-based reclamation（EBR）或 hazard pointer，但 EBR 实现稍重，hazard pointer 需额外管理指针注册
- 最容易忽略的一点：即使用了
std::shared_ptr，也要确保所有线程对同一节点的访问都通过该智能指针，不能混用裸指针——否则引用计数失效
为什么 push 和 pop 的内存序不能都用 relaxed？
因为 relaxed 内存序不提供同步语义，会导致其他线程看到节点数据（比如 data 字段）是未初始化的垃圾值，哪怕 CAS 已成功。
立即学习“C++免费学习笔记（深入）”；
- push 中写节点数据必须在 CAS 更新 head 之前，且用
memory_order_relaxed写数据没问题，但 CAS 必须用memory_order_release - pop 中读 head 后，必须用
memory_order_acquire才能确保看到 push 时写入的完整节点内容 - 如果平台是 x86，relaxed 有时也“碰巧”工作，但这属于架构巧合，换到 ARM 或 RISC-V 就立刻崩溃
真正难的不是写通 CAS 循环，而是确认每个节点生命周期是否被所有线程一致观察到——这取决于内存序、回收机制、节点布局三者严丝合缝的配合。少一环，就变成“看起来跑得通，压测半小时后随机 core”。