单纯用 std::atomic 做无锁栈 pop/push 必遇 ABA 问题，因 CAS 只比对指针值而不验证对象身份，导致地址复用引发 use-after-free 或链表损坏；须用 lock-free 的 tagged pointer（如 uintptr_t+version 打包）或 hazard pointer/RCU 等机制防护。
单纯用 std::atomic<node></node> 做无锁栈 pop/push，一定会遇到 ABA 问题；它不会崩溃、不报错，但会静默破坏链表结构或触发 use-after-free —— 这不是 bug，是 CAS 的固有局限。
为什么 compare_exchange_weak 会“成功地失败”
ABA 不是竞态异常，而是一种逻辑欺骗：CAS 只比对指针值，不关心这个地址背后是不是同一个对象。典型路径是：
- 线程 A 读到
top == A，准备 pop，但在读取A->next后被调度出去 - 线程 B 把 A 弹出、
delete A，再 push 一个新节点，恰好复用了 A 的内存地址（仍是A） - 线程 A 恢复，执行
top.compare_exchange_weak(A, A->next)，发现值还是 A → CAS 成功 - 结果：A 被二次释放，或链表跳过中间节点，形成环/断裂
关键点：错误发生在指针语义层面——A 是地址，不是身份。你无法靠 == 判断“是不是原来那个 A”。
std::atomic<TaggedPtr> 必须满足 is_lock_free()
加版本号不是加个 std::atomic<uint64_t></uint64_t> 就行。两个独立原子变量（指针 + 版本）之间存在读取窗口，仍会看到“新指针 + 旧版本”这种错配状态。
立即学习“C++免费学习笔记（深入）”；
必须打包成单个原子单元，例如：
struct TaggedPtr {
uintptr_t ptr : 48;
uint64_t version : 16;
};
但注意：
- 先检查
std::atomic<TaggedPtr>::is_lock_free()，返回false就别用——某些 x86-64 环境下 16 字节结构体 fallback 到内部互斥锁，既失去 lock-free 意义，又可能死锁 - 成员顺序影响对齐：x86-64 的
cmpxchg16b偏好低地址存指针、高地址存 tag，别颠倒 - 别用
int存版本号：uint64_t防溢出；实际常切 48/16 位，兼顾地址空间与翻转周期
比版本号更稳的方案：hazard pointer 或 RCU
在真实项目中，TaggedPtr 很难彻底规避内存回收复杂性。比如：pop 出的节点要等所有线程都不再引用它，才能安全 delete。这时 hazard pointer 是更落地的选择。
它的核心不是防 ABA，而是防 use-after-free：
- 每个线程声明自己正在访问哪些指针（hazard pointers）
- 回收线程只清理那些未被任何 hazard pointer 标记的节点
- ABA 依然可能发生，但“B 变回 A”时，旧 A 的内存不会被重用 → 地址复用链断开
RCU 更适合读多写少场景：写操作复制+修改+切换指针，读端永远看到一致快照，天然绕过 ABA 和回收时机问题。但它要求读端可容忍旧数据，且写端需等待宽限期。
真正容易被忽略的是：ABA 问题往往不是出现在你写的 CAS 里，而是出现在你依赖的第三方 lock-free 容器中 —— 如果没做版本绑定或 hazard protection，就默认它没解决 ABA。
