必须禁用编译器异常机制并彻底审查标准库、内存分配、第三方库及跨模块调用：GCC/Clang加-fno-exceptions，MSVC用/EHs-；改用下标访问、std::from_chars、std::nothrow new；确保泛型代码依赖noexcept类型，C++模块回调需extern "C"隔离。
编译器层面必须禁用异常机制
不关掉编译器的异常支持，throw 和隐式异常路径（比如 new 失败、动态_cast 失败）仍可能悄悄插入二进制，破坏确定性。GCC/Clang 必须加 -fno-exceptions；MSVC 对应 /EHs- 或更彻底的 /EHsc-（禁用 C++ 异常，但保留 Structured Exception Handling 可选）。仅靠不写 try/catch 没用——标准库组件（如 std::vector::at()、std::string::substr()）在异常启用时默认抛异常，禁用后行为才变为未定义或静默失败。
标准库容器和算法要切换到“无异常安全”用法
禁用异常后，很多标准库函数会改变契约：例如 std::vector::at() 不再抛 std::out_of_range，而是触发未定义行为（UB）；std::map::at() 同理。必须改用下标访问或 find() + 迭代器检查：
std::vector<int> v = {1, 2, 3};
if (idx < v.size()) {
return v[idx]; // 安全，不抛异常
} else {
return -1; // 错误码
}类似地，避免 std::stoi（抛异常），改用 std::from_chars（C++17，纯错误码接口）；避免 std::regex（异常密集），改用轻量解析或预编译状态机。
内存分配必须显式检查，不能依赖 new 抛异常
-fno-exceptions 下，new 默认返回 nullptr 而非抛 std::bad_alloc。但注意：这是“placement new 以外”的默认行为，前提是没重载全局 operator new 并设为 throw()。稳妥做法是始终搭配 std::nothrow：
立即学习“C++免费学习笔记（深入）”；
int* p = new (std::nothrow) int[1000000];
if (!p) {
return ERR_OUT_OF_MEMORY;
}更推荐在热点路径用内存池或 arena 分配器，完全绕过运行时堆判断；若必须用堆，封装一层带错误码的 alloc_safe()，内部调用 malloc 或 mmap 并检查返回值。
第三方库和模板实例化要彻底审查
一个 std::optional<t></t> 看似安全，但如果 T 的构造函数可能抛异常（且你没关异常），模板实例化时仍会生成异常表条目。所有泛型代码必须确认其依赖类型满足 noexcept 要求。对 Boost、Abseil 等库，需确认其构建时也启用了 -fno-exceptions，否则链接时可能出现异常相关符号缺失或 ABI 不兼容。最保险的是只用标头中明确标注 noexcept 的函数，或自己实现最小必要集（比如用 union + 构造标志模拟 optional）。
真正难啃的是跨模块边界——比如 C++ 模块调用 C 接口再回调 C++ lambda，此时即使本模块禁用异常，回调栈上若残留异常帧，仍可能被 std::terminate 捕获。这种地方必须用 extern "C" 隔离，或确保整个调用链路无任何异常逃逸点。
