智能指针（unique_ptr/shared_ptr）通过RAII机制根治裸指针内存泄漏；Valgrind适用于Linux深度检测，ASan跨平台轻量高效，Windows可用CRT调试堆快速验证；工具需配合正确的资源生命周期设计。
用 std::unique_ptr 和 std::shared_ptr 替掉裸指针
绝大多数内存泄漏，根源是 new 出来却忘了 delete，或者异常中途跳出导致释放逻辑被跳过。智能指针能靠 RAII 在作用域结束时自动释放，从机制上堵住这个口子。
-
std::unique_ptr适合独占资源：分配即接管，移动语义安全，零开销；new int[100]就该配std::unique_ptr<int></int>，不是std::unique_ptr<int></int> -
std::shared_ptr用于共享所有权，但必须警惕循环引用——两个shared_ptr相互持有会导致引用计数永远不归零；此时要用std::weak_ptr打断循环 - 别在函数返回值里裸传
new指针，也别把智能指针绑到全局或静态变量上，否则生命周期失控，看起来没泄漏，实则是“延迟泄漏”
Linux 下用 valgrind --leak-check=full 定位泄漏点
Valgrind 是 Linux 环境下最可靠的动态检测工具，它不依赖源码修改，直接监控二进制执行过程中的每次 malloc/free、new/delete，连调用栈都能打出来。
- 编译时务必加
-g（保留调试符号），禁用优化（-O0），否则报告里只显示汇编地址，找不到 C++ 行号 - 运行命令别只写
valgrind ./a.out，要带上关键参数：valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --track-origins=yes ./a.out - 重点关注报告里的
definitely lost（确定泄漏）和indirectly lost（间接泄漏）；still reachable多数是正常存活的全局/静态分配，不用修 - Valgrind 会拖慢程序 10–30 倍，别在压测或实时性要求高的场景跑；也别对多线程频繁锁竞争的程序强用，容易误报
跨平台开发优先启用 AddressSanitizer（ASan）
ASan 编译时注入检测逻辑，运行时开销比 Valgrind 小得多（通常 2–3 倍），且支持 Windows/macOS/Linux，CI 流水线里集成也方便，适合日常开发自检。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- GCC/Clang 下编译加
-fsanitize=address -g即可，MSVC 对应/fsanitize=address（2025 年起已稳定支持） - 它不仅能报泄漏，还能抓越界读写、UAF（use-after-free）、重复释放等更危险的问题，一条命令覆盖多种错误类型
- 注意：ASan 与 Valgrind 不能共存；开启 ASan 后程序会使用特殊内存布局，
valgrind运行会失败或结果不可信 - 如果程序用了内联汇编、自定义堆分配器（如 jemalloc）、或 mmap 大块内存绕过 malloc，ASan 可能漏检——这时得回退到 Valgrind 或 CRT 调试堆
Windows 下用 _CrtDumpMemoryLeaks() 快速验证
VS 自带 CRT 调试堆是最轻量的起步方案，不需要额外安装工具，适合快速确认是否存在基础泄漏，尤其适合小型 demo 或单元测试。
立即学习“C++免费学习笔记（深入）”；
- 在程序入口（如
main()开头）调用_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);，就能在进程退出时自动触发检查 - 泄漏报告会输出到 VS 的“输出”窗口，格式类似：
Detecting memory leaks... Dumping objects -> {123} normal block at 0x00AABCD, 4 bytes long.，配合_CrtSetBreakAlloc(123)可在分配第 123 次时断点 - 它只捕获 CRT 分配器（
malloc/new）的泄漏，不跟踪VirtualAlloc、HeapAlloc等 Win32 API 分配；若项目混用，得搭配 DebugDiag 或 VLD - 别在 Release 模式下指望它起作用——
_CrtXXX系列函数只在 Debug 版本中生效
noexcept 修饰，就会让析构跳过。工具只是放大镜，真正要盯住的是资源生命周期的设计意图——谁创建、谁销毁、异常路径是否覆盖、跨模块边界时所有权是否清晰。 
