Zig Bits 0x2：使用 defer 击败内存泄漏
内容提要
文章介绍Zig中内存泄漏的检测与修复。示例函数用分配器拼接路径后未释放内存。可通过Valgrind（需链接libc）或测试中的std.testing.allocator发现泄漏。修复方法是调用allocator.free释放内存，并用defer在作用域结束时自动清理，也可用errdefer处理错误路径。通用分配器同样能报告泄漏。
延伸解读
Valgrind 检测的局限与前提
文章演示了用 Valgrind 发现内存泄漏，但需要先切换到 C 分配器并在 build.zig 中链接 libc，否则 Valgrind 无法追踪 Zig 默认分配器的分配。这说明 Valgrind 并非开箱即用，且依赖 libc 环境。对于不想引入 libc 的项目，文章更推荐使用 std.testing.allocator 在测试中检测泄漏，因为它更原生且无需额外配置。
defer 的清理时机与作用域
defer 会在当前作用域结束时执行，因此将 allocator.free(path) 紧跟在分配之后，能确保无论函数如何返回，内存都会被释放。文章还展示了用花括号划分独立作用域，让每个作用域内的 defer 各自清理自己的资源。这种写法把资源获取与释放放在相邻位置，比在函数末尾集中 free 更不易遗漏，也避免了 C 语言中清理代码与分配位置相距过远的问题。
通用分配器作为运行时泄漏检查
除了测试，文章还介绍了用 std.heap.GeneralPurposeAllocator 在程序运行时报告泄漏。示例中第二个作用域故意没有 free，运行后 GPA 在退出时打印出泄漏地址和调用栈。这说明 GPA 不仅能分配内存，还能在 deinit 时检查未释放的块，适合在开发阶段替代 page_allocator 来主动发现泄漏。std.testing.allocator 正是基于这一机制实现的。
errdefer 与 defer 的分工
文章指出 defer 在作用域退出时总会执行，而 errdefer 只在作用域因错误返回时执行。示例函数中 defer 打印函数结束，errdefer 打印遇到错误，当传入错误标志时两者依次触发。这种区分让错误路径的清理与正常路径的清理可以分开编写，尤其适合需要在出错时释放已获取资源的场景，替代了 C 语言中 goto error 的清理模式。
Q&A
Zig 里怎么检测内存泄漏？
可以用 Valgrind，但需要把分配器换成 std.heap.c_allocator 并在 build.zig 中链接 libc；更推荐用 std.testing.allocator 写测试，测试运行器会自动报告泄漏。
为什么用 Valgrind 检查 Zig 程序时显示没有泄漏？
因为默认的 std.heap.page_allocator 分配的内存 Valgrind 追踪不到，需要改用 std.heap.c_allocator 并链接 libc，Valgrind 才能正确检测。
defer 在 Zig 里怎么用来防止内存泄漏？
在分配内存后立即写 defer allocator.free(path);，这样在当前作用域结束时会自动释放内存，把资源获取和释放放在一起。
errdefer 和 defer 有什么区别？
defer 在离开作用域时总会执行；errdefer 只在作用域因错误返回时才执行，适合错误路径的清理。
除了测试分配器，还有什么办法能发现内存泄漏？
可以用 std.heap.GeneralPurposeAllocator，并在 main 中 defer _ = gpa.deinit();，这样主程序运行时也会报告泄漏。
defer 除了释放内存还能做什么？
可以用于文件操作，比如打开文件后 defer file.close(); 确保关闭；也可以执行任意代码块，但不能在 defer 中使用 return。
