内存破坏检测需结合运行时钩子与编译器插桩：用 malloc 钩子加红区标记可轻量定位越界，addresssanitizer 则提供精准实时检测；智能指针不防越界，自定义 operator new 易引发递归，无银弹方案。
用 malloc 钩子 + 内存填充检测越界写入
标准 C++ 没有运行时内存破坏检测能力，但可通过拦截 malloc/free 实现轻量级防护。核心思路是在每次分配时多申请几字节，在前后插入固定标记（如 0xDEADBEEF），并在 free 时校验这些“红区”是否被修改。
常见错误现象：程序偶发崩溃、free(): invalid next size (fast)、double free or corruption (!prev) —— 这些都是内存破坏的典型后遗症，但已晚于问题发生点。
- 只拦截
malloc/realloc/free，不碰new/delete（除非重载全局操作符） - 红区大小建议至少 8 字节，太小易被对齐掩盖；太大则浪费内存
- 填充值避免全零或常见模式（如
0x00000000或0xCCCCCCCC），否则越界写入可能恰好不触发校验 - 必须在
free时检查，不能只依赖malloc分配逻辑 —— 破坏常发生在释放前
用 AddressSanitizer 在编译期启用实时检测
AddressSanitizer（ASan）是 Clang/GCC 提供的编译器插桩工具，能捕获堆/栈/全局区的越界读写、使用已释放内存（use-after-free）、双重释放等行为，且定位精准到行号。
它不是“调试技巧”，而是应作为日常开发编译选项存在。一旦关闭，就失去所有保护。
- Clang/GCC 编译加
-fsanitize=address -g，链接时也需保持该 flag - 不要与
-O2以上优化共用 —— ASan 要求未优化的栈帧和变量布局，否则报错位置偏移或漏检 - ASan 会替换
malloc等函数，因此自定义内存分配器若未适配，可能引发误报或崩溃 - 运行时报错形如
heap-buffer-overflow on address 0x60200000001c at pc 0x00010a1b9e75 bp 0x7ffee3b2a9f0 sp 0x7ffee3b2a9e8，配合-g可直接看到源码行
为什么不用 std::shared_ptr 或 unique_ptr 自动防破坏？
智能指针解决的是**生命周期管理**问题，不是内存破坏检测问题。它们无法防止：p->field = 42 写过 p 所指对象末尾、ptr.get()[100] 访问越界、或通过原始指针绕过智能指针直接操作内存。
更隐蔽的问题是：智能指针自身也可能成为破坏目标 —— 若其控制块（control block）被踩坏，后续 shared_ptr 拷贝或销毁就会崩，但此时 ASan 已无法回溯原始越界点。
-
shared_ptr的引用计数存储在堆上独立控制块中，该块本身无红区保护 - 用
get()获取裸指针后，所有越界行为都脱离智能指针监管 - 多线程下若未正确同步访问同一
shared_ptr实例，可能破坏其内部原子计数器，表现为随机崩溃
自定义 operator new 做运行时断言要避开哪些坑？
重载全局 operator new 可以插入边界检查逻辑，但极易引入递归调用或破坏标准库行为 —— 比如 std::string 构造内部可能调用 new，若你的实现又用了 std::vector 存日志，就会死循环。
真正可行的做法是：仅在调试构建中启用，且所有辅助数据结构必须使用 ::operator new（即跳过重载）或静态缓冲区。
- 禁止在重载的
new中调用任何可能触发new的标准库函数（std::cout、std::string、std::map全部不行） - 记录分配信息时，用预分配的环形缓冲区 + 原子索引，避免锁和动态分配
- 检查逻辑必须放在
delete中，而非new—— 因为破坏总发生在写阶段，分配时刻一切正常 - Windows 下还需处理
_aligned_malloc和 CRT 的私有分配器，否则漏检严重
内存破坏检测没有银弹。ASan 是最接近开箱即用的方案，但仅限开发阶段；生产环境若需防护，必须接受性能代价并严格隔离钩子代码 —— 任何试图“悄悄加一层”的做法，最终都会在某个低概率路径上失效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
