@
nebkad 使用者为什么要知道它背后的调度机制如何？使用者只需要知道“只要我把这个函数的返回值用 UniTask 包起来它的 continuation 就一定遵守 unity 的调度行为”。
举个例子：
返回 UniTask 的函数调用一个返回 Task 的异步函数，其中返回 Task 的异步函数是用来做 HTTP 请求，而返回 UniTask 的函数的 continuation 是用来根据响应更新游戏内的对象。
那此时 HTTP 请求的内部行为（比如异步 json 序列化等待）为什么要被扔进 unity 的 event loop ？他们完全可以采用 runtime 的标准调度行为，而等 HTTP 请求结束之后回到 UniTask 这边后，处理结果的时候采用 unity 的调度行为。
这即可以确保你的 HTTP 请求这种跟 unity 无关的东西不会挤占 unity event loop 的调度队列，同时又确保了游戏内 UniTask 的 continuation 全都被正确调度从而不会出现跨 unity 生命周期的游戏对象更新等等。
当然，有些人希望我不用 UniTask 也可以把 continuation 全都调度到主线程上，比如在 WPF 或者 winforms 里，那此时简单通过框架层面设置的同步上下文就可以决定你的 Task 的 continuation 在哪里执行。当然你也可以通过 .ConfigureAwait(false) 来手动针对某一处 await 绕过该行为。
另外我前面解释的一个地方有误，这里纠正一下。
前面说的“有一万种方法在代码中绕过异步框架的调度器，甚至你在中途调用了某些实现垃圾的第三方异步代码给你丢弃掉上下文也不是不可能”并不准确，实际上绕过这种行为只是针对你需要绕过的那一处 await 调用的局部行为，需要显式通过 .ConfigureAwait(false) 指定，使得该 await 之后的 continuation 不使用同步上下文：
async Task Foo()
{
await Bar().ConfigureAwait(false);
A(); // A 的执行将不受同步上下文控制
}
然而该异步函数 Foo 返回后，等待 Foo 的人的 continuation 仍然是遵守同步上下文进行调度的，因此不会产生任何的混乱问题。