崩溃类型

判断"这是哪一类"最快的方法是看崩溃地址：

拿到栈

平台	做法
开发机（IDE）	直接看调用栈，配好符号就行
Windows 现场	生成 dump（minidump），用 WinDbg/VS 打开
Android	`addr2line` 把 tombstone 里的地址还原成行号
iOS	崩溃日志 + dSYM 符号化
Linux	core dump + gdb

# Android 还原（UE 提供 ndk 里的工具链）
aarch64-linux-android-addr2line.exe -f -C -e libMyGame.so 0x0000000000123456

没有符号的栈等于没有栈。发布流程必须包含"保留符号表"这一步——把符号剥离但单独存档（见 Security 里关于符号剥离的代价）。

工具	查什么	代价
AddressSanitizer（asan）	越界、UAF、double free	内存 2–3 倍，速度慢 2 倍
UndefinedBehaviorSanitizer（ubsan）	未定义行为（溢出、对齐全）	较轻
ThreadSanitizer（tsan）	数据竞争	较重
MemorySanitizer（msan）	未初始化读取	需重编所有依赖
Valgrind	泄漏、非法访问	极慢，Linux 用
`_CrtSetDbgFlag`（MSVC）	泄漏检测	轻

asan 是性价比最高的一个：越界写和 UAF 这两类最难查的问题，它能直接指到分配和释放的那两行。

-fsanitize=address -fno-omit-frame-pointer -g

需要重编，且不能与某些自定义分配器直接配合（UE 需要额外配置）。

机制	用途
`check()`	失败即崩（发布版可编译掉）
`verify()`	表达式始终求值，但只在 debug 断言
`ensure()`	失败不崩，上报一次，可继续跑（适合线上）
`ensureAlways()`	每次都上报
`UE_LOG`	日志
`FDebug::DumpStackTraceToLog`	主动打栈
Crash Reporter	自动收集上传
`StompAllocator`	立刻捕获 UAF（页保护）

ensure 与 check 的选择：开发期用 check 尽早暴露；线上用 ensure 避免一崩全崩。

把警告清零后再开启 -Werror，一次性开会在存量代码上淹死人。

1. 拿到栈（符号化）
2. 判断崩溃类型（地址/异常码）
3. 复现（最小步骤）
4. 缩小范围（二分、加日志、条件屏蔽）
5. 上工具（asan / StompAllocator / 增加断言）
6. 定位根因后，补一条断言或单测防回归

第 3 步"复现"是分水岭：能稳定复现的问题基本都能查清；不能复现的，靠的是"崩溃聚合 + 增加诊断信息 + 等下一次"。