悬空指针（dangling pointer）是C++中最隐蔽也最危险的一类内存问题。典型场景是：一个类的成员指针指向了堆上的对象，对象在某处被释放，而这个成员指针依然保存着旧地址，代码继续通过它访问内存，轻则读到脏数据，重则直接崩溃。由于释放和访问往往发生在代码的不同位置，这类bug定位起来非常困难。本文围绕类成员指针的悬空问题，介绍几种工程上经过验证的应对策略。
一、悬空指针是如何产生的
先看一段有问题的代码。下面的类持有一个裸指针，指向一块动态分配的内存：
class Buffer {
public:
Buffer() {
data_ = new char[1024];
}
~Buffer() {
// 忘记 delete[]，内存泄漏
}
char* data() { return data_; }
private:
char* data_;
};
这个例子虽然简单，但暴露了裸指针作为类成员的第一个风险：资源释放依赖程序员手动维护。一旦析构函数忘记释放，就产生泄漏；反过来，如果在对象还存活时就提前delete了这块内存，而成员指针没有置空，后续任何访问都会变成未定义行为。
悬空问题的另一种常见来源是浅拷贝。当Buffer对象被复制时，默认的拷贝构造只会复制指针的值，两个对象实际上共享同一块内存。任何一个对象析构时释放了内存，另一个对象的成员指针就悬空了。此外，多线程环境下对象在别的线程被销毁、回调中持有了已经销毁对象的指针、容器扩容导致旧地址失效（迭代器失效的变体），都属于同一类问题的不同表现。
总结下来，悬空指针的核心成因有三个：释放后未置空、所有权不明确、生命周期不可控。后面的解决方案也都是围绕这三点展开的。
二、用智能指针明确所有权
现代C++（C++11及以后）提供的智能指针是解决悬空问题的首选方案。智能指针的本质是用RAII思想把资源生命周期绑定到对象生命周期上，析构时自动释放资源，不需要手写delete。
unique_ptr：独占所有权
如果这块资源只属于当前类，没有共享需求，用std::unique_ptr最合适。它开销几乎为零，且禁止拷贝，从语言层面杜绝了浅拷贝导致的悬空：
#include <memory>
#include <vector>
class Document {
public:
Document() : pages_(std::make_unique<std::vector<int>>(100)) {}
~Document() = default; // unique_ptr 自动释放，无需手写 delete
private:
std::unique_ptr<std::vector<int>> pages_;
};
注意几点细节。第一，unique_ptr持有数组时要写成unique_ptr<T[]>，析构时会自动调用delete[]而不是delete，用错形式同样是未定义行为。第二，如果类的析构函数在头文件中声明、在cpp文件中定义，而成员是unique_ptr，最好在类内直接写~Document() = default;，避免不完整类型导致的编译错误。第三，unique_ptr可以显式转移所有权（move），转移后源指针自动为空，这本身就避免了"两个指针指向同一对象"的悬空隐患。
shared_ptr与weak_ptr：共享与观测
当资源确实需要被多个对象共享时，用std::shared_ptr。它通过引用计数管理生命周期，最后一个引用销毁时自动释放对象。但shared_ptr有一个前提：所有权关系必须是清晰的，即所有访问者都通过shared_ptr持有对象，而不是混用裸指针和智能指针。混用时，裸指针一方无法参与计数，一旦shared_ptr全部释放，裸指针就悬空了。
对于"只需要访问、不需要拥有"的场景，正确的做法是std::weak_ptr。weak_ptr不增加引用计数，使用前通过lock()提升为shared_ptr，若对象已销毁则返回空指针，可以安全判断：
#include <memory>
#include <iostream>
class Session; // 前置声明
class Connection {
public:
void setSession(std::shared_ptr<Session> s) {
session_ = s; // weak_ptr 可以直接从 shared_ptr 构造
}
void handleMessage() {
if (auto s = session_.lock()) {
// 对象仍然存活，安全使用 s
} else {
std::cout << "session 已销毁，忽略本次消息\n";
}
}
private:
std::weak_ptr<Session> session_;
};
这种组合在回调、缓存、观察者模式中尤其重要。比如网络库中连接对象持有会话的weak引用，会话被销毁后连接再收到数据，lock返回空，逻辑上自然跳过即可，不会崩溃。
三、析构置空与手动清理策略
并非所有代码库都能一步到位改成智能指针，尤其是一些大型遗留项目。此时至少要做到"释放即置空"这条纪律：每次delete之后立刻把指针置为nullptr，成员指针在析构函数中统一清理。
class LegacyCache {
public:
~LegacyCache() {
if (entry_ != nullptr) {
delete entry_;
entry_ = nullptr; // 置空，防止重复析构路径误用
}
}
void reload() {
if (entry_ != nullptr) {
delete entry_;
entry_ = nullptr; // 释放后立即置空
}
entry_ = new Entry();
}
bool valid() const { return entry_ != nullptr; }
private:
Entry* entry_ = nullptr; // 声明时初始化为空
};
置空的价值在于把"未定义行为"变成"可检测的空指针判断"。悬空指针访问时可能"看起来正常"，因为它碰巧读到了尚未被覆盖的旧数据，这种bug往往在上线后才暴露；而空指针解引用会立刻崩溃，问题在现场就能抓住。配合if (ptr)这样的防御性判断，可以显著降低风险。
不过要清醒地认识到置空策略的局限：它只保护了这一个指针变量，其他指向同一对象的指针依然悬空。也就是说，置空解决的是"重复释放"和"本指针误用"，解决不了"多处引用同一对象"的问题。所以工程上的完整建议是：置空作为过渡手段和防御底线，所有权管理最终还是要靠智能指针。
四、工程实践中的补充建议
除了上面两条主线，还有一些经验值得参考。
- 遵循Rule of Five：类持有裸指针资源时，拷贝构造、拷贝赋值、移动构造、移动赋值、析构这五个函数都要认真处理，要么正确实现深拷贝，要么直接delete掉拷贝操作，禁止默认浅拷贝。
- 能用引用和值就不要用指针：成员如果是内部子对象，直接用值成员；需要外部传入且保证非空，用引用或
std::reference_wrapper，减少空指针和悬空的可能。 - 善用工具兜底：AddressSanitizer（编译时加-fsanitize=address）能精准报告use-after-free，Valgrind适合无重编译条件的场景，静态分析工具clang-tidy的cppcoreguidelines规则集也能提前发现owning裸指针的问题。
- 注意回调中的生命周期：异步回调里不要捕获裸this，改为捕获shared_from_this()返回的shared_ptr，或用weak_ptr在回调触发时lock检查。
用一个捕获shared_from_this的例子说明异步场景的正确姿势：
class AsyncTask : public std::enable_shared_from_this<AsyncTask> {
public:
void start(std::function<void(std::function<void()>)> scheduler) {
auto self = shared_from_this(); // 捕获 shared_ptr 保活
scheduler([self]() {
self->onDone(); // 即使其他引用已释放，self 仍保证对象存活
});
}
void onDone() { /* ... */ }
};
最后总结一下：避免类成员指针悬空，核心思路是让资源的生命周期有明确的所有者。独占用unique_ptr，共享用shared_ptr，观测用weak_ptr，遗留代码至少做到释放即置空。再加上Rule of Five和 sanitizers 工具的辅助，悬空指针这类问题完全可以被系统性消除，而不是靠运气规避。