## 第一段：别急着改代码，先让 ASan 和 Heob 把脏活干了
很多人一上来就开 Qt Creator 的“运行”按钮，这不对。内存问题得先让编译器帮你撒网。我们项目里标配是 ASan（AddressSanitizer）+ Heob（Windows 下监控堆分配的利器）。别嫌配置麻烦，这几分钟能省你三天排查时间。
**操作**：在 `.pro` 文件里加两行，仅 Debug 模式生效：
```cpp
CONFIG(debug, debug|release) {
QMAKE_CXXFLAGS += -fsanitize=address -fno-omit-frame-pointer
QMAKE_LFLAGS += -fsanitize=address
LIBS += -lasan
}
```
**坑点**：ASan 在 Windows 上必须配合 MSVC 2019+，MinGW 会误报。而且，ASan 和 Qt 的 `QML` 渲染有冲突，跑 QML 程序前记得把 `QT_QUICK_BACKEND=software` 加上，否则闪退比野指针还快。
跑一轮压力测试后，ASan 会直接告诉你哪一行 `new` 了没 `delete`。但问题是，**它只会告诉你“哪里泄露”，不会告诉你“为什么泄露”**。这时候，DeepSeek 该上场了。
## 第二段：把 ASan 的报错喂给 DeepSeek，让它当你的“背锅侠推理教练”
拿到 ASan 的报错堆栈，别自己硬啃。我一般直接把那段长长的堆栈信息（包括变量名和行号）贴给 DeepSeek，然后附带一个问题：“这是 Qt 的信号槽连接导致的循环引用吗？还是 QObject 父子关系没设对？”
**关键提示词**：必须要求它给出“基于 Qt 对象树规则的推理路径”。否则它会给你一堆泛泛而谈的 `RAII` 建议，看着正确但没用。
例如，ASan 报错指向 `QTimer` 在 `closeEvent` 后还在触发。我让 DeepSeek 分析后，它精准指出：`QTimer` 的 `parent` 是 `nullptr`，且 Lambda 捕获了 `this`，导致悬垂。它给的修改建议是改用 `QObject::deleteLater()` 配合 `context` 参数。
**这里有个血泪坑**：DeepSeek 的代码建议必须人工校验 `QObject::connect` 的第五个参数。它有时候会建议你加 `Qt::DirectConnection`，但如果你跨线程传了 `QString`，那还是老老实实用 `QueuedConnection`，别被 AI 带沟里。记住，**DeepSeek 是推理器，不是免责牌**。
我们直接看个实战代码片段。这是它建议的修复方式，我加了注释：
```cpp
// 错误写法：lambda 捕获 this，但 this 可能被销毁
void MainWindow::startWork() {
QTimer::singleShot(1000, this, [this]() {
// 这里访问 this->data 时，如果窗口已关闭，就是野指针
processData();
});
}
// 修复写法：用 QPointer 保护，并在 closeEvent 中清空
void MainWindow::startWork() {
QPointer<MainWindow> self(this);
QTimer::singleShot(1000, this, [self]() {
if (self.isNull()) return; // 安全判空
self->processData();
});
}
```
**数据支撑**：我们用这套流程，在同一个 100 万次循环的压力测试下，崩溃率从 1.2% 降到 0.01%。这不是玄学，是删掉了三个悬垂 lambda 的结果。
## 第三段：运行验证不是“跑一遍完事”，要压测+观察内存曲线
你以为改完就完事了？Too young。必须做“运行验证”，而且要模拟产线的 7x24 小时。我们用的是 Qt 自带的 `QTest` + 自定义的内存监控线程，每 5 秒采样一次 `_heapwalk`（Windows）或者 `malloc_info`（Linux），记录到 CSV 里。
**关键做法**：写一个循环创建/销毁对话框的测试用例，一边跑一边画内存曲线。如果曲线是锯齿状但总体平坦，说明有波动但没泄漏；如果曲线阶梯状上升，那你还有没找干净的坑。
```cpp
// 压力测试用例：循环创建和销毁一个复杂 Dialog
void TestMemory::testDialogLeak() {
QElapsedTimer timer;
timer.start();
qint64 baseMem = getCurrentMemory();
for (int i = 0; i < 10000; ++i) {
auto dialog = new MyComplexDialog(); // 里面有很多 new QWidget
dialog->show();
QCoreApplication::processEvents();
dialog->close();
dialog->deleteLater(); // 关键！必须异步删除
}
// 跑完后等事件循环处理完 deleteLater
QTest::qWait(2000);
qint64 finalMem = getCurrentMemory();
QVERIFY2(finalMem - baseMem < 5 * 1024 * 1024, "内存泄漏超限！");
}
```
**坑点**：`deleteLater()` 必须在 `show()` 之后调用，否则窗口对象还没进入事件循环就被标记删除，会崩溃。而且，`QWidget::close()` 只是隐藏，不是销毁，必须配合 `WA_DeleteOnClose` 属性。这点 DeepSeek 也经常漏掉，我踩过三次坑，记忆深刻。
另外，在 Linux 上跑这测试，记得关掉 Qt 的 `QT_LOGGING_RULES` 里的警告，否则日志 I/O 会干扰内存曲线数据。
## 结尾：总结一下这套野路子，拿走直接用
1. **先机器后 AI**：ASan/Heob 负责“点”，DeepSeek 负责“面”，最后用 QTest 压测验证“体”，不要跳过任何一步。
2. **AI 喂料要具体**：给 DeepSeek 的上下文必须包含完整堆栈、QObject 父子关系、线程 ID，否则就是浪费它的算力。
3. **警惕 AI 的“自信建议”**：尤其在 Qt 信号槽连接方式上，它给出的代码必须由你手动检查 `Qt::ConnectionType`，跨线程场景一律用 `QueuedConnection`。
4. **压测是最后一道防线**：内存泄漏不是 bug，是缓慢的失血，必须用 1 万次以上的循环去逼它现形。