c++的try/catch无法捕获访问违规、除零、栈溢出等硬件异常，必须使用windows seh机制；__except表达式须返回exception_execute_handler等标准常量，不可用true或1；混用seh与c++异常需/eha编译选项以确保析构函数执行；__finally是唯一可靠清理入口，但禁止抛异常或触发新seh。
C++ 的 try/catch 完全捕获不到访问违规、除零、栈溢出这类崩溃，必须用 Windows 原生的 SEH 机制——这是唯一能在进程终止前拿到控制权的机会。
__except 表达式必须返回标准常量，不能写 true 或 1
常见错误是把 __except 当成 C++ 的 if 来用，比如：
__except (GetLastError() != 0) { /* ... */ } // ❌ 返回非标准整数，行为未定义
filter-expression 不是布尔判断，它必须明确返回以下之一：
-
EXCEPTION_EXECUTE_HANDLER：交由当前__except块处理 -
EXCEPTION_CONTINUE_SEARCH：跳过本 handler，继续向上查找 -
EXCEPTION_CONTINUE_EXECUTION：尝试恢复执行（仅限极少数可恢复异常，如EXCEPTION_SINGLE_STEP）
典型安全写法：
__except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
GetExceptionCode() 只能在 filter-expression 中直接调用；提前存到变量里再用，结果不可靠。
/EHa 编译选项是混用 SEH 和 C++ 对象析构的前提
如果你在 __try 块里声明了 std::vector、std::unique_ptr 或其他带析构函数的对象，又想让它们在崩溃时被正确清理，必须用 /EHa 编译，而不是默认的 /EHsc。
否则会出现：
-
/EHsc+__try/__except→ 析构函数完全不调用，资源泄漏 -
/EHa→ 析构函数会被调用，但性能略低，且若析构中抛出 C++ 异常，会触发嵌套崩溃
混合模块场景（C++ 主工程调用含 SEH 的 C 静态库）下，主工程也必须统一用 /EHa，否则链接后崩溃位置难以定位。
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
__finally 是唯一能保证执行的清理入口
当发生严重异常（如访问违规）时，__try 块里的 return、goto、甚至 exit() 都可能被跳过，但 __finally 块一定执行（进程被强制终止除外）。
这是释放系统资源的最后机会，例如：
-
CloseHandle()关闭文件或事件句柄 -
VirtualFree()释放虚拟内存 -
DeleteCriticalSection()销毁临界区
注意：__finally 块内禁止抛 C++ 异常、禁止触发新 SEH（如解引用空指针），否则会导致二次崩溃。
SetUnhandledExceptionFilter 是全局兜底，不是替代 __try/__except
SetUnhandledExceptionFilter() 注册的是线程级的“最后防线”，只在异常没被任何 __try/__except 捕获时才触发。它适合做崩溃上报和 dump 生成，但不适合精细控制流程。
关键区别：
-
__try/__except：局部、主动、可恢复逻辑分支（比如重试 malloc） -
SetUnhandledExceptionFilter：全局、被动、仅用于记录和善后（弹窗 +MiniDumpWriteDump）
两者要配合使用：高频易错路径用 __try 局部防护；全局兜底用 SetUnhandledExceptionFilter 防止漏网。
真正难处理的不是语法，而是异常发生时栈已损坏，任何“恢复执行”的尝试都极其危险——SEH 不是 try/catch，它介入的是操作系统级异常调度链，稍有不慎就会掩盖真实问题或引发更隐蔽的崩溃。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
