野指针是已释放内存的地址仍被持有并访问，主因是delete/free后未置空、返回局部指针、未初始化即解引用；应统一用smart pointer、声明即初始化、启用ASan/UBSan检测。
野指针不是“指针坏了”，是“指针还活着但指向废墟”
野指针本质是已释放内存的地址仍被持有并尝试访问，delete 或 free 后没置空、局部指针返回、未初始化指针直接解引用——这三类占实际项目中 90% 以上问题。它不一定会立刻崩溃，可能静默读错数据、改写邻近内存，等出问题时早已偏离源头几十行代码。
最直接的应对不是靠经验规避，而是让“悬空”这件事在编译期或运行期尽可能暴露出来：
-
delete后立刻赋值为nullptr（C++11 起推荐），避免二次delete或误用 - 禁用裸指针跨作用域传递：函数返回局部对象地址？直接报错；返回堆对象？改用
std::unique_ptr或std::shared_ptr - 所有指针变量声明即初始化：
int* p = nullptr;，别留int* p;这种“等着出事”的写法
用 std::unique_ptr 替代大部分 new/delete 手动管理
手动配对 new/delete 在异常路径下极易漏掉清理，而 std::unique_ptr 的析构函数保证资源释放，且不可复制、可移动——天然匹配“单一所有权”场景。
常见误用：
立即学习“C++免费学习笔记（深入）”；
- 把
std::unique_ptr绑定到栈对象上：int x = 42; auto p = std::unique_ptr<int>(&x);</int>→ 程序结束时会delete &x，UB - 用
get()拿原始指针后长期持有：int* raw = ptr.get(); /* ... */ *raw = 10;→ 若ptr提前释放，raw立刻变野指针 - 传入 C 风格 API 后忘记考虑所有权移交：
some_c_api(ptr.release());是正确移交，some_c_api(ptr.get());是危险借用
示例：安全替换裸指针工厂函数
std::unique_ptr<Widget> create_widget() {
return std::make_unique<Widget>(42); // 自动管理，无需 delete
}调试阶段必须开 ASan + UBSan，别信“我测试过了没崩”
野指针访问未定义行为（UB），标准不保证任何表现，包括“恰好正常”。GCC/Clang 的 AddressSanitizer（ASan）能捕获绝大多数堆上野指针读写，UndefinedBehaviorSanitizer（UBSan）能抓到 delete 后解引用这类操作。
关键点：
- 链接时加
-fsanitize=address,undefined，运行时会直接报错并打印调用栈，定位到具体哪行用了野指针 - ASan 会显著拖慢速度、增大内存占用，但这是调试期的必要代价；上线前关掉即可，不影响逻辑
- Windows 上 MSVC 的
/fsanitize=address支持有限，建议用 Clang-cl 或切 Linux/macOS 环境做 ASan 测试 - 注意：ASan 对栈上野指针（如返回局部数组地址）检测能力弱，这类必须靠静态分析（如 clang++
-Wreturn-stack-address）或 Code Review 卡死
成员指针别乱用 this，尤其别在构造函数里“发出去”
构造函数尚未执行完，对象处于半初始化状态，此时把 this 交给其他对象（比如注册回调、塞进容器、启动线程），对方若立即访问成员变量，很可能读到未初始化的垃圾值，甚至触发虚函数表未就绪导致崩溃——这不算传统野指针，但危害相当，且更隐蔽。
典型错误模式：
- 在构造函数里调用
std::thread([this]{ do_something(); });→this可能被子线程在构造完成前使用 - 基类构造期间调用虚函数 → 实际调用的是基类版本，哪怕派生类已重写，因为虚表指针还没更新
- 把
this存入全局 map 或单例管理器，但析构顺序无法控制，可能导致析构后仍有代码通过该指针访问
可行做法：用两阶段初始化，或延迟到 init() 函数中再发布 this。
野指针问题从来不在“怎么写新代码”，而在“怎么封住旧习惯的漏洞”——比如忘了置空、图省事用裸指针传参、跳过 sanitizer 直接上线。越底层的模块，越要默认禁用裸指针，越要让编译器和工具替你盯住那些“本不该发生的访问”。
