4. 动态内存越界：malloc/free越界、new/delete越界、内存泄漏关联
动态内存越界，说白了就是你在堆上申请了一块内存，结果读写操作跑到了边界外面。这个问题比栈上越界更隐蔽，也更难排查。我早期做嵌入式开发时，就因为这个坑，整整熬了三个通宵。
4.1 malloc/free 越界：C 语言的老毛病
先看一个典型的例子：
char *p = (char *)malloc(10); // 申请10个字节
strcpy(p, "Hello, World!"); // 源字符串14字节，越界4字节
free(p); // 崩溃？不一定，但迟早出事为什么会这样？malloc 只保证你申请的 10 个字节可用。你多写了 4 个字节，这 4 个字节可能属于：
- 堆管理器的元数据（比如下一个空闲块指针）
- 另一个已分配的内存块
- 空闲链表中的节点
我在项目中遇到过最诡异的情况：程序运行三天后突然崩溃，查到最后就是 malloc 越界写坏了堆管理器的链表指针。嗯，这种问题用 valgrind 一跑就现原形。
警告：free() 释放越界内存时，堆管理器会读取被破坏的元数据，大概率直接段错误。这不是「偶尔崩溃」，而是「迟早崩溃」。
4.2 new/delete 越界：C++ 的坑更深
C++ 的 new 和 delete 本质上还是调用 malloc 和 free，但多了构造和析构的步骤。越界问题更复杂：
int *arr = new int[5];
arr[5] = 100; // 越界！索引0-4有效
delete[] arr; // 可能崩溃，也可能不崩你想想看，new[] 会在分配的内存前面额外存一个计数值（记录元素个数）。如果你越界写到了这个计数值的位置，delete[] 调用析构函数时就会乱套。
个人经验：我建议在 new 数组时，多申请一个哨兵元素。比如需要5个，就 new int[6]，用 arr[5] 作为边界检测位。虽然浪费一个元素，但排查问题时能救命。
4.3 内存泄漏：越界的「孪生兄弟」
越界和泄漏经常一起出现。举个例子：
void func() {
char *buf = new char[64];
// 处理数据...
if (some_error) {
return; // 忘记 delete[]，泄漏！
}
delete[] buf;
}更隐蔽的情况是越界导致泄漏：
char *p = (char *)malloc(32);
p += 10; // 指针偏移了10字节
free(p); // 释放的不是原始地址，行为未定义！
// 原始内存泄漏了，而且可能触发堆损坏我曾经接手过一个服务端项目，内存占用每天涨 2MB。查了三天，发现是一个 realloc 调用后没更新指针，旧指针还在用，新指针丢了。这就是越界 + 泄漏的经典组合拳。
4.4 排查工具与实战技巧
| 工具/方法 | 适用场景 | 我的评价 |
|---|---|---|
| valgrind (memcheck) | Linux 下 malloc/free 越界、泄漏 | 神器，但会让程序慢 10-20 倍 |
| AddressSanitizer (ASan) | GCC/Clang 编译时加 -fsanitize=address | 比 valgrind 快，推荐日常开发用 |
| CRT 调试堆 (Windows) | _CrtSetDbgFlag 检测泄漏 | VC++ 项目标配 |
| 自定义内存池 | 高频分配/释放场景 | 一劳永逸，但需要额外开发量 |
避坑指南：我曾经在 release 版本中遇到一个越界 bug，debug 下跑 valgrind 完全正常。最后发现是编译器优化导致的内存布局变化。所以我的习惯是：release 版本也要保留 ASan 的测试构建。
4.5 核心逻辑：动态内存越界排查流程
下面这张图是我自己总结的排查思路，你照着走一遍，90% 的问题都能定位：
4.6 预防胜于治疗
说几个我自己的习惯：
- 申请时多留 4 字节：在末尾写一个固定魔数（比如 0xDEADBEEF），释放前检查魔数是否被改写。一旦被改，说明有越界。
- 释放后立即置空：
free(p); p = NULL;防止野指针。 - 用智能指针：C++ 项目里，
std::unique_ptr和std::shared_ptr能省掉 80% 的泄漏问题。 - 写单元测试时覆盖边界：比如申请 10 字节，故意写第 11 字节，看程序会不会崩溃。
一个小技巧：我习惯在
malloc 后立即用 memset 初始化为 0。这样越界读到的数据不会是随机值，更容易在调试时发现异常。
动态内存越界这东西，说白了就是「出来混迟早要还的」。你写错一个字节，可能三天后才会暴露。但只要你掌握了正确的排查方法，再配合工具，这些坑都能填平。