这个异步操作应该怎么写？

拆接口。
前端拿到 json 后，再次用那个 json 请求另一个接口来执行你那个“特别耗时的计算”，等待这个“特别耗时的计算”的同时，前端可以用这个 json 做其他的事情。

你的意思是接口返回的数据不需要等待计算完成，计算的结果不需要返回给前端？
那直接 spawn task 就好了。

@Buges 耗时的计算方法的返回结果不需要马上返回给前端，当他再去自己调用结果的时候，再给他

1.后面的处理另开一个线程
2.使用消息队列

@DOLLOR 拆接口确实是个好方法，只是当拿到第一段 json 然后又马上进行二次请求的时候，前端页面是不是就会暂时卡死？我是希望前端拿到一段 json 后就可以开始展示页面了，用户该干嘛干嘛，然后我后台还在继续算，算完的结果也没必要马上通知给前端，而是当他再度调用到需要这个结果的功能的时候再返回给他

https://stackblitz.com/edit/rxjs-it7obd?file=index.ts

这样是么

@qtoq126 前端只要拿到第一次请求的 json 就可以开始渲染了，第二次请求是不会阻塞渲染的。

@DOLLOR 相当于用户可以任意操作，前端只是在后台默默请求？

@wunonglin ts 代码看不懂哇

@qtoq126 对的，这本来就是异步请求的初衷。

@qtoq126 那就 spawn 到后台执行的同时返回一个 task id ，前端等待一段时间再用这个 id 请求第二个接口结果，如果尚未完成返回 pending 让前端等待一段时间再次请求。注意第二个接口只返回状态和结果而不要调用执行。
不单单拆接口，所有的接口处理函数中都不要同步等待结果维持连接。你想想你等待的时候连接超时了、中断了，或者用户刷新了重新发送。

所有接口都应该不要阻塞，尽快返回。前端无论如何都不应做“耗时”的请求，即使在后台。

@ration 重开一个线程的话，当我使用 return 返回第一段 json 后，主线程会不会就已经结束了啊？如果主线程已经结束了的话，Task.Run()运行的耗时函数可能还没拿到结果

@Buges 谢谢大佬点拨，你说的这个思路我能理解，就是具体到 api 的编写和异步函数的编写上面的话，就不知道怎么去做了

@qtoq126 返回只是结束你这个请求的 handler 函数啊，主程序和后面的线程池都是一直在运行的。除非你是 php 那样用 cgi 一个请求起一个进程。
具体实现很直接啊，第一个接口请求后 Task.Run 把耗时计算 spawn 到后台（不要 await ），并生成一个 UUID ，把这个 UUID 作为 key 和上面返回的 Task 存到一个共享的 ConcurrentDictionary 里面，并把这个 UUID 作为额外的字段加到 json 里返回给前端。
第二个接口前端拿这个 UUID 作为参数请求，拿到后通过这个 UUID 取得上面存的 Task 并检查 Task.Status 是否已经完成，未完成就返回 pending ，完成就返回结果（和释放资源）。

前端请求先第一个接口拿到 json 和 UUID 先渲染，然后等待一段时间在用 UUID 请求第二个接口，如果为 pending 那就等待一段时间重试直到拿到结果。

如果你期望的是”执行步骤 3“且不关心返回值”，可以利用 Hangfile 库的 BackgroundJob.Enqueue 方法。

不对啊，你说的第五点怎么和我印象里的不太一样。我记得，哪怕你不 await ，只要主程序不结束运行，你的异步方法还是会完整的执行下去的，只不过在异步方法的外部没法捕获异常。

代码类似这样
https://gist.github.com/frisktale/809ab236c93d1d6967f01cde49fc9528

成熟的方案就是队列

伪代码：_=一个返回值为 Task 的方法；
这样就不会等待了，方法还是会执行的，也不需要用 Task.Run 之内的再封装了

@llwuuzz 我试试你说的这种方案