另外补充一点，Unity 在框架层面也确实设置了同步上下文，因此你直接使用 Task 也不会有问题。
UniTask 的出现更多只是为了解决 Task 的分配问题（这一点 UniTask 内部通过池化和循环利用 awaitable 对象解决，而 runtime async 不存在这种问题），以及提供强保证防止误用（毕竟 UniTask 不提供 ConfigureAwait(false) 这种临时在局部扔掉同步上下文的方法）。即使没有 UniTask 你在 Unity 中全使用 Task 也不会出现什么问题。

等到 runtime async 出来之后我是能预计到会有相当一大部分的人从自定义 Task 类型回归到内置的 Task 的。

@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 仍然是遵守同步上下文进行调度的，因此不会产生任何的混乱问题。

@nebkad C# 的各种 Task 实现不一定非得实现调度器，这个完全是可选的；而调度器本身也可以通过外部上下文传入使得与 Task 解藕。也就是说两种模式是同时支持的。
然而通过外部上下文来控制调度器并不具备强制性，有一万种方法在代码中绕过异步框架的调度器，甚至你在中途调用了某些实现垃圾的第三方异步代码给你丢弃掉上下文也不是不可能。而在类型里实现调度的话则能保证只要你在用这个类型就能得到 100%可预测的行为。

@nebkad UniTask 和 GDTask 哪怕有 Runtime Async 也是有必要存在的，因为需要自定义调度器实现。
比如 PIE 停止后需要停止调度 continuation ，自带的 Task 显然做不到，因为 async/await 的调度行为需要在 Task 或者 Task-like 类型来实现。

@nebkad 不知道你在说什么，runtime async 等待异步事件还真就可以不需要堆分配，不然文中递归调用 FibAsync 的测试中性能也不可能比得上同步版本。

@lizy0329 是的，UI 开发里 ECS 在其它语言里都是可选项，而且有比 ECS 更直观和方便的做法；但是在 Rust 中 ECS 是必须项，没这玩意你写不出代码。

简单的 hello world 可以，但是但凡正经一点的 UI 用 rust 就是自找不痛快，包括游戏、GUI 都是同理。
UI 的特性天生就是共享状态需要允许多方同时持有非只读引用，然而 Rust 不会允许你这么做，于是最后你不得不把整个 ECS 那套搬进 GUI 开发里，最后带来的反而是生产力下降。

同样用的 edge 浏览器进行 bing 搜索没有遇到任何问题。
会不会是什么插件导致的？建议跑一下 profiler 。

@drymonfidelia 过来人告诉你，用 UE 的结果就是人生大半时间耗费在编译上，然后代码一不小心没写好编辑器直接跟着崩溃退出，一天光 UE 编辑器就得重启好几次。然后 Blueprint 还是二进制格式，碰到了冲突你根本没法自动合并，然后这个二进制文件还经常会因为 hot reload 的 bug 又或者 C++代码那边的关系/依赖变动而损坏导致你整个文件没法打开或者编译。

@suruiran Go runtime 的特性其实也决定了 Go 不适合用来做动态链接库。如果一定要做动态链接库的话，建议更换其他语言，比如 C/C++/Rust ，又或者 C# 走 NativeAOT 编译出 native dll ，这些都是没问题的，并且同一个进程多 dll 共存也没有问题。

一个进程内无法加载多个 go 的 runtime ，参考官方仓库的 issue： https://github.com/golang/go/issues/50304#issuecomment-999302888
并且他们也没有计划修复。

@Leon6868 Avalonia 可以 NativeAOT 直接编译到机器码在目标系统上无需 runtime 直接原生运行，甚至包括 wasm 平台在内。不知道你所说的“通用”是什么，任何的应用框架都会绑定到一个特定语言或者平台上，不存在什么所谓的通用的框架。

@hez2010 以及多引用几个模块再装几个插件之后，虚幻引擎照样编译一次等几分钟

等你真的开始用虚幻引擎做开发了，就会知道这玩意一天能崩溃十几次。

其实微软现在靠 AI 给 Azure 狠狠的加了一把柴火，现在市场份额 AWS 仍然是领先的 29%，但是 Azure 已经追到 22%了，对比之下 GCP 只有 12%。
之前手上的一个项目用到了 GCP ，我是真的从来没用过像 GCP 那种往一个页面里塞一大堆东西和折叠框的让你找东西找不着的反人类 UI ，和各种过度包装的 API 设计，就光说给 GitHub Actions 分配一个 access token 你就得前前后后配置一大摊子，只能说活该份额低。

Windows 的 UI 各自都是独立的 COM 组件，而 explorer 中的组件也同理，因此在同一个 host （窗口）上你可以根据配置来随意组合各种控件使用，也就造成了不同的入口在同一个进程的同一个窗口上却能加载出来两种完全不同的 UI 实现。
能做到这一点恰恰说明 Windows 在架构上很优秀，模块化做的非常好，组件之间全部都是解耦合的，可以随时添加也可以随时剥离。只不过为了兼容性很少删除旧的组件，因此你还是能通过某些方式调出来。

Azure 是允许按照订阅管理员的要求来自定义什么资源可以部署什么资源不能部署的，估计是你们公司管理员专门把 Public IP Address 给关了。
不过 Azure 的虚拟机没有公网 IP 也可以创建，你可以创建之后再部署个 Azure VPN 服务啥的访问你的虚拟机。

@drymonfidelia 不应该，按理来说应该是会出现性能数据总结的
换成 /clp:PerformanceSummary /tl:false 试试呢？

可以试试给 dotnet build 加几个参数：-clp:PerformanceSummary -tl:false
这样能看到编译时间到底花在了具体哪个任务上