野指针本质是访问已释放或未初始化的内存地址，源于生命周期管理失控，需通过严格配对new/delete并置空、禁用局部地址返回、慎用智能指针原始指针混用等手段防控。
野指针的本质是访问已释放或未初始化的内存地址
野指针不是“指针坏了”，而是它指向的内存已经不属于当前程序合法使用范围——比如 delete 后没置空、栈对象析构后仍被外部持有、局部指针返回给调用方等。这类问题在运行时往往不立即崩溃，而是随机触发 segmentation fault 或读到脏数据，调试成本极高。
核心对策不是靠运气检查，而是从生命周期管理入手：谁分配、谁释放、谁持有、何时失效，必须有明确归属。
new/delete 必须成对且指针立即置为 nullptr
这是最基础也最容易被跳过的一步。C++ 不会自动把 delete 后的指针设为 nullptr，后续误用 if (p) 判断毫无意义。
-
delete p;之后必须紧跟p = nullptr;，哪怕只是临时变量 - 避免
delete p;后再delete p;（双重释放），置空后第二次delete nullptr是安全的 - 如果用的是
new[]，必须配delete[]，混用会导致未定义行为 - 建议优先用智能指针替代裸指针，但若必须用裸指针，这条规则不能妥协
不要返回局部对象的地址或引用
函数栈帧退出后，所有局部变量（包括局部对象、数组、std::string 临时量等）的内存即失效。此时返回其地址，得到的就是典型野指针。
立即学习“C++免费学习笔记（深入）”；
- 错误示例：
int* get_ptr() { int x = 42; return &x; }——x在函数返回瞬间销毁 - 错误示例：
const char* get_str() { return std::string("hello").c_str(); }—— 临时std::string析构后，c_str()返回的指针悬空 - 正确做法：返回值语义（如
std::string）、静态存储（慎用）、或由调用方传入缓冲区 - 编译器（如 GCC/Clang）加
-Wreturn-stack-address可捕获部分此类问题
使用智能指针时也要警惕“假安全”陷阱
std::shared_ptr 和 std::unique_ptr 能解决大部分资源泄漏和悬挂问题，但不是万能的。常见误区包括：
- 用原始指针构造
shared_ptr后，继续用该原始指针操作对象（如delete raw_p;），导致双重释放 -
shared_ptr循环引用（如 A 持有 B 的shared_ptr，B 也持有 A 的），造成内存泄漏 —— 此时应改用weak_ptr打破循环 - 从
shared_ptr.get()获取原始指针后，误以为可以长期持有；一旦shared_ptr生命周期结束，该指针立刻变野 - 跨 DLL/so 边界传递智能指针需确保 ABI 一致，否则可能引发析构异常或内存管理错位
真正难缠的野指针，往往藏在看似“安全”的智能指针 + 原始指针混用场景里。只要出现 get()、release()、reset() 这类操作，就得重新审视所有权是否清晰。
