_CrtDumpMemoryLeaks() 是 Windows 下最轻量的泄漏检测方式，仅需在 main 开头调用 _CrtSetDbgFlag 并启用调试堆，程序退出时自动报告未释放内存，但无调用栈且依赖正常返回。
用 _CrtDumpMemoryLeaks() 在 Windows 下快速捕获泄漏
Windows 平台下最轻量、无需额外工具的泄漏检测方式，依赖 MSVC 的 CRT 调试堆。它只在程序退出时打印未释放的堆块摘要，不提供调用栈，但胜在开箱即用。
关键点：
- 必须在程序入口（如
main()）开头调用_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); - 确保使用调试版（
/MDd或/MTd），且定义了_DEBUG - 泄漏报告中显示的文件名和行号，依赖于在
#include <crtdbg.h></crtdbg.h>前定义_CRTDBG_MAP_ALLOC - 若程序有多个出口（如提前
exit()或异常终止），泄漏可能不被触发——需确保正常返回到main末尾
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#include <iostream>
<p>int main() {
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
int* p = new int[100];
// 忘记 delete[] p;
return 0; // 此处触发检查
}Linux/macOS 下用 valgrind --leak-check=full 定位源头
valgrind 是跨平台事实标准，但仅适用于 Linux/macOS（macOS Catalina+ 需注意系统限制）。它能精确指出每一块泄漏内存的分配位置，包括函数名、源码行、调用栈。
常见误操作：
立即学习“C++免费学习笔记（深入）”；
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 未用
-g编译，导致报告里只有地址没有符号——务必加g++ -g -O0 - 忽略
--track-origins=yes：对“未初始化值”间接导致的泄漏排查很有用 - 误以为
--leak-check=summary够用：它只报总数，漏掉具体泄漏点 - C++ 异常路径未覆盖：若构造函数抛异常，
new分配后未匹配delete，valgrind 会如实报告
g++ -g -O0 leak.cpp -o leak valgrind --leak-check=full --show-leak-kinds=all ./leak
用 AddressSanitizer（ASan）在编译期注入运行时检查
Clang/GCC 支持的 ASan 不仅查内存泄漏，还查越界、UAF、栈使用后释放等。相比 valgrind，它更快（约 2× 慢），且支持多线程，适合 CI 或日常开发启用。
启用方式简单，但有几个硬性前提：
- 必须链接 ASan 运行时：GCC/Clang 默认已包含，但若静态链接或交叉编译需显式加
-fsanitize=address - 不能与
valgrind共存（二者都劫持 malloc/free） - 默认不开启泄漏检测：需额外加
-fsanitize=address -fno-omit-frame-pointer -g并设置环境变量ASAN_OPTIONS=detect_leaks=1 - 某些 STL 容器（如
std::string的 SSO 优化）可能触发误报，可加detect_stack_use_after_return=1细化控制
g++ -fsanitize=address -fno-omit-frame-pointer -g leak.cpp -o leak ASAN_OPTIONS=detect_leaks=1 ./leak
为什么 RAII 和智能指针不能完全避免泄漏？
RAII 是 C++ 抗泄漏的核心机制，但真实项目中仍有三类典型漏点：
-
std::shared_ptr循环引用：两个对象互相持有对方的shared_ptr，引用计数永不归零——改用std::weak_ptr打破循环 - 裸指针被临时“托管”但未移交所有权：例如函数返回
new出的指针，调用方忘记包装成unique_ptr - 全局/静态对象析构顺序不确定：A 的析构函数中访问 B 的静态成员，而 B 已析构，可能导致释放逻辑跳过或崩溃，间接掩盖泄漏
- 第三方库内部泄漏：比如用了
dlopen加载的插件未调用对应dlclose，ASan 和 valgrind 能发现，但无法直接修复
真正难排查的，往往不是 new 没配 delete，而是资源生命周期跨越模块边界、析构时机不可控、或工具链本身对某些分配模式（如 mmap、自定义 allocator）无感知。
