使用Try-Catch-Finally处理API端点代码的弊端有哪些？

场景背景：
负责的API端点要求最多几秒内返回OK响应，原有代码先执行DoLotsOfWork()再返回响应，若方法超时则无法返回OK。建议采用队列异步处理方案被否决，被要求使用以下写法：

public IActionResult DoWork([FromBody] MyDTO myDto){
   try{
       return OK();
   }
   catch{
   }
   finally{
      DoLotsOfWork();
   }  
}

以下是这种写法的关键弊端：

• 请求上下文丢失风险：ASP.NET Core框架在返回OK()后，会立即开始回收或复用当前请求的上下文（如HttpContext）。如果DoLotsOfWork()依赖请求上下文里的资源（比如用户身份信息、请求头参数、关联的数据库上下文），大概率会出现空引用、资源已释放的异常，甚至引发不可预期的程序崩溃。

• 任务执行无可靠性保障：

  • DoLotsOfWork()执行中出现异常时，因为已经返回了OK，调用方完全无法感知任务失败，既没有重试机会，也无法做错误降级处理；
  • 若应用进程在finally块执行过程中意外终止（比如服务重启、内存不足被系统杀死），任务会直接中断，既没有重试机制，也不会留下失败记录，导致业务操作丢失。

• 线程池资源被阻塞：DoLotsOfWork()是同步执行的，会持续占用处理请求的线程池线程。短时间内大量请求进来时，线程池会被这些耗时任务占满，后续新请求无法被及时处理，直接导致API吞吐量暴跌，甚至引发服务雪崩。

• 监控与排查难度剧增：

  • 任务执行的日志、错误信息无法和原请求关联，因为请求已经返回，无法通过请求ID追踪任务的执行链路；
  • 无法统计任务的执行成功率、耗时等核心指标，难以排查性能瓶颈或定位故障原因。

• 违背HTTP语义规范：HTTP的200 OK状态码代表请求已被成功处理完成，但实际上此时任务才刚开始执行。调用方会误以为操作已完成，可能在任务未执行完毕时就进行依赖该任务的后续操作，进而导致数据不一致的问题。

内容的提问来源于stack exchange，提问作者Xerc