hez2010

今天试了试 Gemini 3.0 Pro 诊断我手上的 UDP 网络通信库为什么会在流量大的时候接收端突然收到本不应该收到的 FIN 信号终止连接，结果它分析了半天又是内存安全问题又是数据结构对齐问题又是大小端问题，还反反复复对着同一个地方复读老半天，等了好几分钟最后改了一大堆代码，结果啥用都没有。
然后换了 GPT-5.1-Codex ，同样是分析了好几分钟，也尝试了各种方向，但是很快就得到结论不是代码实现的 bug ，开始朝着数据完整性的方向思考，最后给我加入了 checksum 拦截掉经过网络传输后变得不正确的数据，问题解决。
问题确实不出在终端软件而是在链路上。这么看还得是 GPT-5.1-Codex 更胜一筹。
不过想发挥 GPT-5.1 的全部实力，你得要能触发 high thinking 才行，于是得在 prompt 上下下功夫让模型的 router 认为你这个问题需要大量思考。

顺带一提，在 .net 11 即将到来的 async2 中，直接返回一个 Task 而不是标记成 async 在里面 await 后返回这种代码是负优化，可能会导致性能下降。

另外补充一点，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 开发里，最后带来的反而是生产力下降。