29、内存管理最佳实践：编码规范、代码审查、测试
说实话，内存管理这块，很多人觉得「懂了 malloc/free 就完事了」。但我在实际项目中摔过太多跟头，才明白——真正的高手，靠的是规范、审查和测试这三板斧。今天咱们就聊聊，怎么把这套东西落地。
核心观点：内存管理不是写代码时的灵光一现，而是一套可执行、可检查、可验证的工程流程。
一、编码规范：从源头堵住漏洞
我见过太多人，写代码时随手一个 malloc，完事就忘了 free。你想想看，这种习惯不改，后面审查和测试再牛也救不了。所以，规范是第一道防线。
1.1 命名规范：让内存变量「自报家门」
我个人习惯，所有动态分配的内存指针，命名里都要带个 p_ 前缀，或者用 _buf、_ptr 结尾。比如：
// 好的命名
char *p_buffer = (char*)malloc(1024);
int *p_data = (int*)calloc(100, sizeof(int));
// 糟糕的命名
char *buf; // 是静态的还是动态的？
int *arr; // 谁负责释放？为什么这么做？因为代码审查时，一眼就能看出哪些变量需要关注释放问题。我在项目中就吃过亏——一个叫 temp 的指针，三个人都没发现它没被释放，最后内存泄漏查了整整两天。
1.2 配对原则：malloc 和 free 要「成双成对」
这是铁律。我建议你在写 malloc 的同时，就把对应的 free 写出来。哪怕先写个空函数占位，也比事后补强。
// 推荐写法：先写分配，再写释放框架
void process_data() {
int *data = (int*)malloc(100 * sizeof(int));
if (!data) return;
// ... 业务逻辑 ...
// 释放（先写出来，防止忘记）
free(data);
data = NULL; // 我习惯顺手置空
}小技巧：我习惯在 free 之后立即把指针置为 NULL。这样如果后面误用了，程序会立刻崩溃，而不是产生难以追踪的野指针问题。
1.3 所有权规则：谁分配，谁释放
说白了，就是每个动态内存块都要有一个明确的「主人」。函数 A 分配的内存，要么由 A 释放，要么在文档里明确说明「调用者负责释放」。
| 场景 | 所有权 | 示例 |
|---|---|---|
| 函数内分配，函数内释放 | 函数自身 | malloc → 使用 → free |
| 函数分配，返回给调用者 | 调用者 | create_buffer() → 调用者 free |
| 传入指针，函数内重新分配 | 调用者（需文档说明） | realloc_buffer(&ptr, size) |
我曾经在一个大型项目中，就是因为所有权不清晰，导致两个模块互相推诿「该你释放」，最后内存泄漏了 200 多 KB。从那以后，我要求团队每个函数都要在注释里写明内存所有权。
二、代码审查：用「四只眼睛」找问题
代码审查不是走过场。我见过太多团队，审查时只看逻辑对不对，却忽略了内存问题。其实，内存相关的 bug 往往藏在细节里。
2.1 审查清单：我常用的 5 个检查点
- 检查每个 malloc/calloc/realloc 是否有对应的 free —— 这是最基本的，但也是最容易漏的。
- 检查错误路径 —— 函数中间 return 时，之前分配的内存释放了吗？
- 检查 realloc 的返回值 —— 很多人直接
ptr = realloc(ptr, size)，如果 realloc 失败，原指针就丢了。 - 检查数组越界 —— 分配了 N 个元素，却访问了第 N+1 个。
- 检查结构体中的指针 —— 释放结构体时，内部的动态成员释放了吗？
注意：realloc 的正确用法是先用临时变量接收返回值，检查成功后再赋值给原指针。否则一旦失败，原内存块就泄漏了。
// 错误写法
ptr = realloc(ptr, new_size); // 失败则 ptr 变 NULL，原内存泄漏
// 正确写法
void *tmp = realloc(ptr, new_size);
if (tmp) {
ptr = tmp;
} else {
// 处理错误，ptr 仍然有效
}2.2 审查流程：我推荐「三遍法」
第一遍，快速扫读，看整体结构。第二遍，逐行审查，对照清单。第三遍，专门看内存操作——把所有 malloc/free 都圈出来，一个一个对。
嗯，这个方法看起来笨，但确实有效。我团队里有个小伙子，刚开始觉得麻烦，后来有一次审查时发现了一个隐藏了三个月的内存泄漏，他当场就说：「这方法真香。」
三、测试：用工具和数据说话
规范和审查是「防患于未然」，但测试才是最后的「照妖镜」。你想想看，代码写得再漂亮，跑起来内存泄漏，那都是白搭。
3.1 单元测试：覆盖边界条件
我写单元测试时，特别关注这几个场景：
- 分配 0 字节 —— 有些实现会返回 NULL，有些会返回非 NULL 指针，要明确行为。
- 分配超大内存 —— 比如
malloc(SIZE_MAX)，看程序会不会崩溃。 - 重复释放 —— 对同一个指针 free 两次，看会不会 double free。
- 使用已释放的内存 —— 故意在 free 后访问指针，看能不能检测出来。
// 一个简单的测试示例
void test_double_free() {
int *p = (int*)malloc(sizeof(int));
assert(p != NULL);
free(p);
// 第二次 free 应该触发错误（如果开启了调试）
// free(p); // 这行在测试中注释掉，但审查时要检查
printf("test_double_free passed\n");
}3.2 工具辅助：Valgrind 和 AddressSanitizer
说实话，人工测试只能覆盖一部分。真正的大杀器，是工具。
| 工具 | 能检测什么 | 使用方式 |
|---|---|---|
| Valgrind (Memcheck) | 内存泄漏、越界、使用未初始化内存 | valgrind --leak-check=full ./program |
| AddressSanitizer (ASan) | 越界、use-after-free、double free | 编译时加 -fsanitize=address |
| UBSan | 未定义行为（包括指针运算错误） | 编译时加 -fsanitize=undefined |
我个人强烈推荐 AddressSanitizer。它比 Valgrind 快得多，而且集成在 GCC/Clang 里，开箱即用。我在 CI 流程里强制开启了 ASan，跑不过就不允许合并代码。
实战建议：在开发阶段用 ASan（速度快），在回归测试阶段用 Valgrind（检测更全面）。两个工具互补，基本能覆盖 95% 的内存问题。
四、知识体系总览
下面这张图，是我对内存管理最佳实践的总结。你可以把它当作一个检查清单，每次写代码时对照一下。
五、写在最后
内存管理这件事，说白了就是「认真」二字。规范让你少犯错，审查帮你发现漏网之鱼，测试给你最后的信心。这三者加起来，就是一个靠谱的工程流程。
我记得刚入行时，带我的老工程师说过一句话：「内存管理不是技术问题，是态度问题。」当时我不理解，现在回过头来看，确实如此。你愿意花多少心思在规范、审查和测试上，你的代码就有多稳定。
好了，这一章就到这里。希望你能把这些实践用起来，少踩一些我当年踩过的坑。