ASP.NET Core WebAPI 首次HTTP调用失败时非阻塞二次调用方案选型
各方案优缺点对比
Task.Run/Task.Factory.StartNew
优点：实现最简单，无需额外配置
缺点：① 服务重启/关闭时不会收到通知，正在执行的任务会被直接终止，未执行的任务直接丢失；② 不会自动管理依赖注入作用域，请求结束后Scoped生命周期的服务会被释放，直接调用会触发ObjectDisposedException；③ 大量并发任务会挤占线程池资源，影响正常接口请求处理
适用场景：仅适合测试环境、极小流量内部服务，且第二次调用丢失完全不影响业务的场景，不推荐生产环境使用QueueBackgroundWorkItem
优点：比Task.Run稍可靠，服务正常关闭时会给后台任务最多30秒（默认）的缓冲时间执行完
缺点：① 进程异常崩溃时任务仍然会丢失；② 仍然需要手动处理依赖注入作用域；③ 无队列容量控制，高并发下可能出现任务丢失
适用场景：已过时，更推荐用官方的QueuedHostedService方案替代QueuedHostedService（官方后台队列实现）
优点：① 原生无第三方依赖，实现可控；② 可自定义队列容量、并发处理数，资源占用可控；③ 服务正常关闭时会优雅等待正在处理的任务完成；④ 可手动在任务消费端创建依赖注入作用域，避免对象释放问题
缺点：任务存储在内存中，进程异常崩溃时未消费的任务会丢失
适用场景：对可靠性有中等要求，可接受极端场景下少量任务丢失，不想引入第三方组件的生产场景Hangfire
优点：① 任务持久化存储（支持数据库、Redis等），进程崩溃、服务重启都不会丢失任务，保证至少执行一次；② 自动管理依赖注入作用域，无需手动处理；③ 内置重试、任务调度、监控面板等能力，可直观查看任务执行状态，失败后可手动重试
缺点：需要引入第三方依赖，额外配置持久化存储，增加少量架构复杂度
适用场景：对第二次调用可靠性要求高，不允许任务丢失，需要生产级监控、重试能力的高流量场景自定义单例队列实现
本质和QueuedHostedService逻辑类似，需要自己处理线程安全、队列溢出、优雅关闭等逻辑，非常容易写出隐性bug，除非有特殊定制需求，否则完全不推荐自己造轮子
选型建议
- 业务场景简单、第二次调用丢失完全无影响：选Task.Run，注意手动创建依赖注入作用域，并且捕获所有任务异常避免进程崩溃
- 无特殊可靠性要求、不想引入第三方组件：选官方QueuedHostedService，直接复用微软官方提供的实现代码即可，稳定无额外成本
- 生产环境、要求任务不丢失：直接选Hangfire，虽然需要少量配置，但后续运维、排查问题的成本低很多，可靠性远高于原生内存队列方案
其他注意事项
- 你贴出的代码存在几处小问题需要先修复：构造函数中
_httpClientFactory = httpClientFactory应该改为_httpClientFactory = factory，序列化时的body变量实际应该是传入的request参数 - 无论选择哪种方案，后台任务的所有异常必须全部捕获，不要让未处理的异常抛到线程池，否则会导致进程退出
- 如果第二个接口涉及数据写入，一定要保证接口幂等性，避免任务重试时产生脏数据
内容的提问来源于stack exchange，提问作者Mahesh Jadhav
