ASP.NET Core API控制器中未await的后台任务是否会被中断丢失？

你的顾虑完全合理，你列的4种直接调用不await的写法，都存在任务丢失、中途终止的风险。

风险核心原因 #

• 第一类风险：服务生命周期触发的终止。ASP.NET Core进程遇到部署更新、进程回收、服务器重启、负载缩容等场景时，所有未受框架托管的后台Task都会被直接终止，不会等待执行完成。你提到的这些写法启动的Task都属于线程池后台任务，没有任何生命周期保护，这类场景下必然会丢失。
• 第二类风险：依赖作用域销毁导致的异常。如果你的DoSomething60sAsync方法中用到了请求作用域注入的服务（比如EF Core的DbContext、请求相关的配置等），请求返回后作用域会立即被销毁，后续任务执行到依赖这些服务的逻辑时会直接抛出异常，导致任务中断。
• 第三类风险：未处理异常导致进程崩溃。你用弃元_ = xxx的写法等于完全放弃了任务的异常处理，如果任务执行过程中抛出未捕获的异常，.NET运行时默认会触发进程终止，直接影响整个服务的可用性。

关于你提到的几个写法的疑问 #

• 4种写法本质上没有区别，全都是不受托管的后台任务，Task.Run在这里确实没有实际意义：DoSomething60sAsync本身是async方法，调用后已经会把后续逻辑交给线程池调度，Task.Run只是多了一层无意义的包装。
• DoSomething60sAsync循环内线程ID变化是正常现象：async/await的状态机执行机制下，await操作结束后不会强制回到原线程执行，ASP.NET Core没有同步上下文，所以每次await结束后都会从线程池随机取一个空闲线程继续执行，所以线程ID会变化。

实现方案选择建议 #

• 如果你的任务允许极端场景下少量丢失（比如非核心的日志上报、统计类任务），也可以用弃元写法，但必须做两个改造：一是任务逻辑里不要依赖请求作用域的服务，所有依赖要单独创建作用域获取；二是给任务加全局异常捕获，避免异常拖垮整个进程。但还是非常不推荐这种写法，稳定性完全没有保障。
• 如果想要稳定可靠的简单实现，优先用官方自带的IHostedService搭配后台任务队列，框架会托管后台任务的生命周期，服务关停时会预留缓冲时间让正在执行的任务收尾，能覆盖绝大多数场景的需求。
• 如果任务要求必须执行、不能丢失，甚至服务重启后也要续跑，直接用Hangfire这类第三方组件即可，自带持久化、重试、失败告警能力，不用自己重复造轮子。

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