编译器不会因捕获块写法而关闭内联，jit或编译期内联决策取决于方法体大小、调用频率、异常结构复杂度等；应避免在热路径使用try/catch，优先用前置检查替代被动捕获，并保持catch块轻量。
编译器不会因为捕获块的写法而“关闭内联”——这是对内联机制和异常处理语义的常见误解。java 和 c# 等主流语言的 jit 编译器（如 hotspot、.net core clr）在运行时决定是否内联方法，其依据是方法体大小、调用频率、是否含异常处理结构（如 try/catch）、是否有未处理的异常路径等，而非“捕获块是否被重构”。c++ 编译器（如 msvc、clang）虽在编译期做函数内联，但 catch 块本身不阻止内联；真正影响内联的是：方法是否标记为 noexcept（c++）、是否含复杂控制流、是否跨模块调用、是否抛出/传播异常等。
别把异常处理逻辑塞进热路径
高频调用的方法若包含 try/catch，尤其 catch 块非空或涉及对象构造，会显著增加 JIT 内联拒绝概率。这不是编译器“关闭内联”，而是内联收益评估失败。
- 将可能抛异常的 IO、解析、转换等操作提取到独立方法中，主流程保持无异常结构
- 例如：把
parseJson(input)从循环体内移出，改为预校验 + 单次解析 - 避免在
for循环里写try { doWork(); } catch (e) { log(e); }
用状态检查替代被动捕获
对可预判的异常（如空引用、除零、文件不存在），优先用前置判断代替 catch，既提升性能，也消除异常路径对内联的干扰。
- C# 中用
int.TryParse替代int.Parse+ catch - Java 中用
Objects.nonNull(obj)或 Optional 判断，而非依赖 NullPointerException 捕获 - 数据库操作前检查连接状态，而不是靠
SQLException回滚
确保 catch 块足够轻量且不改变控制流
JIT 更倾向内联不含异常出口的方法。若必须保留 try/catch，需让编译器“相信”它极少触发且开销可控。
- catch 块只做日志记录（
logger.warn(...)）或设标志位，不新建对象、不调用虚方法、不进入锁区域 - 避免在 catch 中 throw 新异常（尤其是包装异常），这会引入额外栈帧和异常对象分配
- 不要在 catch 或 finally 中 return —— 这会破坏方法契约，使内联优化失效
针对 C++ 的特别提醒
MSVC 在 /EHs 模式下不捕获 SEH（如除零、访问违例），此时空 catch(...) 实际不生效，还触发 C4571 警告。若真需结构化异常保护：
- 改用
__try / __except块，它不影响函数内联决策 - 或启用
/EHa并明确声明noexcept(false)，但需承担析构函数不总被调用的风险 - 更稳妥的做法是：关键计算前做数值校验（如
if (divisor != 0)），从源头规避 SEH
