最直接方式是调用_controlfp(_EM_INVALID | _EM_ZERODIVIDE | _EM_OVERFLOW, _MCW_EM)，清除对应异常掩码位以启用x87 FPU异常捕获，触发后通过SEH（__try/__except）处理EXCEPTION_FLT_DIVIDE_BY_ZERO等异常。
Windows下用_controlfp启用FPU异常最直接的方式
在MSVC编译的Windows程序中，_controlfp是控制x87 FPU异常掩码的底层接口。它不依赖C标准库浮点环境，也不受/fp:strict以外编译选项干扰，适合需要精确捕获溢出、除零、无效操作等场景。
关键不是“设成什么值”，而是“清除哪些位”——FPU默认把所有异常都屏蔽了（掩码全开），你要做的是关掉对应掩码位：
-
_controlfp(0, _MCW_EM)：清空整个异常掩码（危险，慎用） -
_controlfp(_EM_INVALID | _EM_ZERODIVIDE | _EM_OVERFLOW, _MCW_EM)：只开这三项，其他仍屏蔽 - 注意第二个参数是掩码掩码（mask），不是要设置的标志——它是告诉函数“我要改哪几位”
调用后，一旦触发对应异常（比如1.0 / 0.0），线程会立即收到EXCEPTION_FLT_DIVIDE_BY_ZERO（Windows SEH异常），可被__try/__except捕获。
Linux/macOS必须用feenableexcept且需确认glibc版本
feenableexcept是POSIX.1-2008引入的接口，但glibc直到2.23才完整支持（Ubuntu 16.04+、CentOS 7.3+）。老系统上它可能返回-1且不生效，别只看返回值就以为成功了。
立即学习“C++免费学习笔记（深入）”；
启用方式简单，但有隐含前提：
- 必须在
#include <>fenv.h>后加#pragma STDC FENV_ACCESS(ON)，否则编译器可能优化掉浮点状态访问 -
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW)返回0才表示真正生效 - 它只影响当前线程；fork后的子进程不继承，pthread_create的新线程需重新调用
- 某些CPU（如ARM64）或内核配置下，
FE_INVALID可能无法触发信号，得靠feclearexcept+轮询
触发后默认发SIGFPE，可用signal(SIGFPE, handler)或sigaction捕获——但注意：不能在信号处理函数里调用printf/malloc等非异步信号安全函数。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
为什么std::fetestexcept不能替代异常捕获
std::fetestexcept只是读取当前浮点状态寄存器的异常标志位，它本身不触发中断，也不改变任何行为。你得自己定期轮询，而且标志位一旦置位就不会自动清零（除非手动feclearexcept）。
典型误用场景：
- 在循环里反复计算却不调用
feclearexcept(FE_ALL_EXCEPT)→ 第二次fetestexcept还返回真，误判为新异常 - 期望它像Python的
try/except一样自动中断执行流 → 它完全不打断代码执行 - 跨函数调用后状态丢失 → x87状态寄存器在函数调用时可能被编译器保存/恢复，导致标志位不可靠
它适合事后诊断（比如计算完检查是否发生过溢出），不适合实时拦截。
混合模式下SSE与x87异常可能不一致
现代编译器默认用SSE指令做float/double运算（/arch:AVX或x64默认），此时_controlfp对x87掩码的修改无效，而feenableexcept控制的是MXCSR寄存器——两者作用对象不同。
常见现象：
- Windows下用
_controlfp开了除零异常，但float a = 1.0f / 0.0f没崩 → 因为实际走的是SSE的divss指令，不受x87掩码控制 - 解决方法：强制用x87（
/arch:IA32）或改用_mm_setcsr操作MXCSR（需手写SSE intrinsic） - 更稳妥的做法：统一用
feenableexcept（POSIX）或SEH+SetThreadExceptionPort（Windows高级用法），避开指令集差异
真正上线前务必在目标平台用objdump或调试器确认实际执行的是哪条浮点指令。
