C++ 标准中不存在也永不加入 std::hazard_pointer；它既非已批准 TS，也未进入 C ++26 草案，当前仅见于 Boost、folly 等非标实现，内存回收仍需手动组合原子操作与外部机制。
目前没有 std::hazard_pointer，C++26 标准中也 ** 不会加入它 **。这是个常见误解——它既不是已批准的 TS（技术规范），也没进入 C++26 的工作草案（如 N4981、N4993）。
为什么 你搜到的“C++26 hazard pointer”大多是误传？
这类说法通常混淆了以下几件事：
- Boost.Lockfree 曾实验性提供
boost::lockfree::hazard_pointer，但它从未成为 ISO C++ 标准提案 - 某些编译器（如 GCC 的
libstdc++）或第三方库（如 folly、abseil）实现了类似机制，但属于扩展，非标准 - WG21（C++ 标准委员会）近年讨论过内存回收方案（如
std::memory_reclamation概念提案），但明确搁置了 hazard pointer 方案，转而倾向更通用的 epoch-based 或 RCU-like 接口
当前 无锁 编程中，内存回收真正依赖什么？
主流实践仍是手动组合原子操作与外部回收机制，没有标准封装：
-
std::atomic只保证指针本身的原子读写，不管理其所指对象生命周期 - 必须配合用户实现的延迟回收逻辑：比如用
std::shared_ptr（但有性能开销）、或自定义 hazard pointer 池 + 周期性扫描 + 内存屏障 - 典型错误是忘记在读取指针后“标记存活”，导致其他线程提前
delete—— 这正是 hazard pointer 想解决的问题，但标准没给
如果你真想用 hazard pointer，现在能怎么做？
只能靠非标方案，且需谨慎评估兼容性与维护成本：
立即学习“C++ 免费学习笔记（深入）”；
- 用
folly::HazardPointer（Facebook 开源）：API 类似经典论文实现，但绑定 folly 生态，不跨平台轻量 - 用
urcu（Userspace RCU）：Linux 用户态成熟方案，支持静默等待（quiescent state），但需要线程显式注册 / 退出 - 自己实现最小集：至少要包含线程局部 hazard pointer 数组、全局待回收链表、
std::atomic_thread_fence(std::memory_order_acquire)保证可见性
// 简化示意：一个 hazard pointer“声明存活”的关键动作（非标准！）struct hazard_ptr {static thread_local std::atomic current; static void set(void* p) {current.store(p, std::memory_order_relaxed); } }; // 注意：这不能防止 p 被 delete，仅作示意；真实实现需配套回收端扫描逻辑 真正容易被忽略的是：即使未来某天 C++ 加入类似设施，它也不会“简化”无锁编程本身——只是把最难缠的内存回收部分从每个数据结构里抽出来复用。写对 compare_exchange_weak 循环、处理 ABA、保证发布顺序，这些依然得自己扛。
