野指针崩溃必然发生，关键在何时爆发；应通过初始化为nullptr、delete后置空、用unique_ptr/weak_ptr管理生命周期、启用asan检测等手段从编译期和运行期根除。
野指针崩溃不是“会不会发生”的问题，而是“什么时候爆发”的问题——它往往在 release 模式下静默破坏数据，直到某次偶然的内存复用才触发段错误。最有效的避免方式不是靠人眼检查，是让野指针在编译期或运行期根本无法存活。
声明即初始化：别留 int* p; 这种裸露状态
未初始化指针的值是栈上随机垃圾，解引用几乎必崩。C++ 不会帮你填 nullptr，必须自己写。
-
int* p = nullptr;是底线，不是可选项 - 类成员指针同样适用：
player_t* m_target = nullptr;，别依赖构造函数后期赋值 - 用
auto p = static_cast<int>(nullptr);</int>强制显式意图，避免隐式转换干扰 - 启用编译器警告：
-Wuninitialized（GCC/Clang）能捕获部分漏初始化场景
delete 后立刻置空：delete p; p = nullptr; 必须成对出现
释放后不置空，p 就变成悬空指针。后续任意一次 if (p) { *p = ... } 都可能踩雷——哪怕你写了判空，判的也是“是否为空地址”，不是“是否还有效”。
- 把
delete p; p = nullptr;当作原子操作，写在同一行或紧邻两行，别拆开 - 宏封装风险高（如
#define SAFE_DELETE(p) delete p; p = nullptr;），易在if (cond) SAFE_DELETE(p); else ...中出错；推荐函数模板：template<typename t> void safe_delete(T*& p) { delete p; p = nullptr; }</typename> - 注意：对
new[]必须用delete[]，混用会 UB，且置空逻辑不变
用 std::unique_ptr 替代 90% 的裸指针堆分配
手动配对 new/delete 在异常路径、提前 return、多出口函数里极易遗漏，而 std::unique_ptr 的析构是 RAII 保证的，哪怕 throw 了也一定释放。
- 直接替换：
auto ptr = std::make_unique<int>(42);</int>，不用new int(42) - 传参时用值传递（转移所有权）或 const 引用（只读访问），避免裸指针交接：
void process(const std::unique_ptr<int>& p);</int> - 切忌用
get()提取原始指针长期持有：int* raw = ptr.get();→ 若ptr在别处被 move 或析构，raw立刻变野 - 跨 C API 边界时，明确所有权：
some_c_api(ptr.release());表示移交，some_c_api(ptr.get());表示借用——后者需确保ptr生命周期覆盖整个 C 函数调用
检测比预防更可靠：AddressSanitizer 是上线前必跑项
再严格的编码规范也防不住团队协作中的疏漏。ASan 能在运行时精准定位野指针访问点，包括 use-after-free、heap-buffer-overflow 等，且性能开销可控（约 2×）。
- 编译加
-fsanitize=address -g，链接加-fsanitize=address - 触发野指针时，输出含完整调用栈、内存分配/释放位置、访问偏移量，比 core dump 直观十倍
- CI 流程中集成 ASan 构建 + 单元测试，能拦截绝大多数野指针隐患
- 注意：ASan 对栈上野指针（如返回局部变量地址）检测能力有限，这类仍需靠代码审查和静态分析（如 Clang-Tidy
cppcoreguidelines-pro-bounds-array-to-pointer-decay）
真正难防的不是单个野指针，而是对象生命周期与指针生命周期错位——比如 monster_t 持有 player_t*，但 player_t 被销毁时无人通知 monster_t。这种场景下，std::weak_ptr 才是正解，而不是反复检查 if (p)。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
