异常结构（如try/except）导致jit跳过编译，因setup_except等字节码被标记为不可编译；移除异常结构或改用防御性检查可恢复jit优化。
方法频繁抛出异常会直接破坏 JIT 编译器的热点识别与优化逻辑——因为异常处理结构（如 try/except）引入的字节码（如 SETUP_EXCEPT、POP_EXCEPT）被主流 JIT 后端（包括 CPython 3.14/3.15、HotSpot、GraalVM Python）明确标记为“不可编译”或“高风险路径”，导致函数被永久排除在 JIT 流程之外，始终以解释模式执行。
确认异常是否阻断 JIT 编译
检查目标函数是否含 JIT 不支持的字节码：
- 用
dis.dis(func)查看函数字节码，重点搜索SETUP_EXCEPT、SETUP_FINALLY、YIELD_FROM、RAISE_VARARGS等指令 - 若存在，该函数默认不会进入 JIT 编译管道，无论调用次数多高
- 运行时验证：启用日志后观察是否缺失
[JIT] Compiling function 'xxx'输出
区分“异常发生”和“异常结构存在”
JIT 失效源于代码中**存在异常处理语法结构**，而非运行时是否真的抛出异常：
- 即使
except块永远不执行（例如try: return 42; except ValueError: pass），只要字节码含SETUP_EXCEPT，JIT 就跳过编译 - 真正影响性能的是“结构存在”+“高频调用”，二者叠加导致：解释开销持续累积 + 无机器码加速补偿
- 可通过移除
try/except并重测调用耗时变化来隔离影响
替代方案：绕过异常结构的 JIT 友好写法
对纯计算型热路径，优先用防御性检查替代异常控制流：
- 用
isinstance(x, expected_type)或hasattr(obj, 'attr')替代try/except AttributeError - 用
dict.get(key, default)替代try/except KeyError - 对数值运算，预检输入范围（如
if x 改为 <code>if x 或提前返回错误码） - 将异常处理逻辑下沉到非热路径（如顶层调度层），保持核心算法函数为“纯、无异常、类型稳定”
监控与验证 JIT 实际行为
不依赖主观感受，用可量化指标判断：
- 首次调用延迟 > 5ms 且后续调用耗时下降 ≥40% → JIT 已生效
- 首次调用延迟 ±15% → 极可能未触发编译（异常结构是首要怀疑对象）
- 启用
PYTHONJIT_LOG=3或-XX:+PrintCompilation，搜索日志中是否出现目标函数名及 “not compilable”、“excluded”、“unstable” 等关键词
