含异常处理的函数通常不被内联，因throw不可预测、catch增加栈帧复杂度且需生成eh表；有效方案是将异常逻辑移出热路径，如前置校验、返回result封装、提取纯子方法。
直接重构捕获块本身并不能让编译器对含异常的函数开启内联——因为内联与否主要由函数体结构、调用上下文和优化策略决定，而 try/catch 块的存在本身就会显著降低内联概率。现代 JIT（如 .NET 6+）和 AOT 编译器普遍将含异常处理逻辑的函数标记为“非内联候选”，尤其当 catch 块中包含变量捕获、资源清理或跨栈帧恢复行为时。
为什么含 try/catch 的方法通常不被内联
编译器内联的前提是能静态确定控制流与副作用边界。而异常路径具有以下不可预测性：
- throw 指令可能在任意位置触发，破坏调用链的线性假设
- catch 块可能引用局部变量、闭包或 this 引用，增加寄存器压力与栈帧复杂度
- JIT 需为每个含异常处理的方法生成额外的 EH（Exception Handling）表条目，增大代码体积，违背内联“小而热”的启发式原则
真正有效的替代方案：把异常逻辑移出热路径
不是“绕过”内联限制，而是让核心逻辑满足内联条件，再将异常处理解耦：
- 前置校验 + 无异常分支：将可能抛异常的输入检查（如 null、范围、格式）提前到调用方，使被调用方法成为纯计算逻辑，不含任何 try/catch
-
返回结果对象代替抛异常：用 Result
或 ValueTask > 封装成功/失败，让调用方统一处理，被调用方法保持无异常语义 - 提取可内联的纯子方法：把 try 块中实际计算的部分（如 ParseIntCore、ValidateEmailPattern）抽成 static、无捕获、无异常的私有方法，显式调用它
编译器层面的辅助手段（需谨慎）
某些场景下可配合编译器提示增强内联机会，但不保证生效：
- 对纯校验/转换类方法添加
[MethodImpl(MethodImplOptions.AggressiveInlining)]，前提是它确实不 throw - 避免在热方法中使用
throw new ArgumentException(...)字面量构造——改用预分配的静态异常实例（如static readonly ArgumentException EmptyArg = new(...)），减少堆分配干扰 JIT 判断 - 在 Release 构建中确认未启用
/optimize-或DebuggableAttribute的 DisableOptimizations 标志，否则 JIT 会主动禁用内联
归根结底，这不是“规避”问题，而是理解内联的本质约束后做架构适配：让高频执行路径干净、确定、无副作用；把异常当作控制流的边界，而非嵌入在热函数内部的装饰。
