悬挂指针是已指向被释放内存的指针，解引用会导致未定义行为；delete后立即置nullptr可使崩溃明确、易定位；智能指针通过RAII机制从根本上避免该问题。
悬挂指针是什么，为什么一用就崩
悬挂指针是已经指向被释放内存的指针，它本身还存着旧地址，但那块内存早已归还给系统或被复用。这时候再解引用（比如 *p 或 p->field），行为未定义——可能读到垃圾值、触发段错误、偶然跑通但逻辑错乱，甚至在不同编译器/优化等级下表现不一致。
常见触发场景：delete p 后没清空 p，后续又误用；函数返回局部变量地址；容器重分配后原有迭代器/指针失效却继续使用。
delete 后立刻赋 nullptr 是最基础的防御手段
这不是“可选习惯”，而是 C++ 中对抗悬挂指针成本最低、效果最直接的实践。只要 delete（或 delete[]）完，马上把指针设成 nullptr，后续解引用会直接崩溃（而不是静默错乱），且崩溃点明确，便于定位。
-
delete p;和p = nullptr;必须成对出现，不能只写前者 - 对
new[]分配的数组，必须用delete[] p;+p = nullptr;，混用delete会导致未定义行为 - 多个指针可能指向同一块内存（比如别名），只清一个没用；需确保所有副本都置空，或改用智能指针统一管理
为什么不用智能指针就更容易踩坑
裸指针不带所有权语义，编译器不会帮你检查生命周期。你得自己记住谁 new、谁 delete、谁还在用——人在复杂调用链里很容易漏掉某处 delete，或重复 delete，或忘记置空。
立即学习“C++免费学习笔记（深入）”；
对比来看：std::unique_ptr 在析构时自动 delete 并置空内部指针；std::shared_ptr 用引用计数，对象真正销毁时才释放内存。它们从机制上杜绝了“释放后仍可解引用”的路径。
- 局部作用域优先用
std::unique_ptr：构造即接管，离开作用域自动清理 - 需要共享所有权时用
std::shared_ptr，但注意循环引用风险（可用std::weak_ptr打破） - 千万别把
new出来的地址传给多个裸指针再各自delete——这是典型的双重释放源头
调试时怎么快速发现悬挂指针
运行时崩溃不一定当场暴露问题根源。比如 p 在 A 函数被 delete 后没置空，B 函数再用它，崩溃发生在 B，但根因在 A。
- 启用 AddressSanitizer（ASan）：Clang/GCC 下加
-fsanitize=address，能捕获释放后使用、栈溢出等内存错误，并给出具体行号和调用栈 - Debug 模式下可重载
operator new/delete，记录分配/释放地址，在解引用前检查该地址是否已释放（适合自研工具链） - 静态分析工具如 Clang Static Analyzer 或 PVS-Studio 能识别部分明显模式，比如
delete p;后无条件使用p
置空指针不能解决所有问题，但它把“不确定崩溃”变成“确定崩溃”，把“难定位”变成“好定位”。真正的难点从来不在怎么写 p = nullptr，而在于整个模块里有没有统一的资源归属约定、有没有人绕过 RAII 直接裸 new/delete、以及多人协作时是否默认信任了“他应该已经置空了”这种假设。
