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、保证发布顺序，这些依然得自己扛。
