.NET 没有纤程支持，因 CLR 从不使用且已移除纤程依赖；async/await 是编译器生成的状态机，非真正协程；线程是唯一操作系统级调度实体。
.NET 中没有纤程（Fiber），协程也非原生语言特性，只有线程是操作系统级的调度实体；所谓“协程”在 C# 中实际是编译器生成的状态机（async/await），不是独立执行单元。
为什么 .NET 没有纤程（Fiber）支持
纤程是用户态轻量级执行上下文，需手动切换（如 Windows 的 CreateFiber、SwitchToFiber），但 .NET 运行时（CLR）从不使用、也不暴露纤程 API。.NET Core / .NET 5+ 更是完全移除了对纤程的任何隐式依赖（比如早期 CLR 曾用纤程模拟部分 GC 暂停行为，现已废弃）。
- 你无法在 C# 中创建或切换纤程——
Fiber类型不存在，System.Threading中无相关类型 - 试图 P/Invoke
CreateFiber会破坏 GC 堆栈遍历和异常处理，导致不可预测崩溃 - 微软明确不推荐、不支持在托管代码中混用纤程
async/await 不是协程，而是状态机编译模式
C# 的 async 方法在编译后变成一个实现 IAsyncStateMachine 的结构体，由 Task 调度器驱动，不拥有独立栈或抢占式调度能力。
将提醒同步至 Windows/Outlook 日历。用户提及「提醒我」「设置提醒」「加到日历」「同步到日历」「日程」「calendar」「日历」时触发。支持Microsoft Graph API 设备代码流认证，无需 Web 服务器，直接写入用户 Outlook 日历。
- 它不保存完整寄存器/栈状态，只捕获局部变量到状态机字段中
- 挂起点（
await）必须是Task-like 类型，且最终依赖线程池线程或同步上下文执行回调 - 没有
yield到指定协程、也没有resume控制权——控制流交还给调度器，而非另一用户代码 - 对比 Lua/Python 的协程：C# 没有
coroutine.create、coroutine.resume这类运行时协作调度原语
public async Task<int> FetchValueAsync()
{
await Task.Delay(100); // 编译为状态机跳转，不是“让出当前协程”
return 42;
}线程是唯一真正的并发执行载体
.NET 中所有可抢占、可并发、可独立调度的执行单位，只有 Thread 实例（或其抽象如 ThreadPool 线程、Task 背后的线程池线程）。
-
Thread对应 OS 级线程，有独立栈、内核对象句柄、可被系统调度器抢占 -
Task默认在ThreadPool上执行，复用线程资源，但本质仍是在线程上跑委托 - 即使
async方法在await后恢复，也大概率回到另一个线程池线程（除非显式ConfigureAwait(false)或处于 UI 同步上下文） - 没有“协程绑定线程”的概念：C# 不提供
go（Go）、task（Rust）那种轻量并发原语
容易被误解的“协程类库”
社区存在如 Unity 的 IEnumerator + StartCoroutine、或第三方 AsyncEnumerator 库，它们只是基于 MoveNext() 的轮询模拟，并非真正协程：
- Unity 的
Coroutine本质是主线程上的帧循环轮询，不能跨线程、不释放 CPU、无调度器参与 - 任何基于
yield return的枚举器都必须由外部循环调用MoveNext()，无法自主挂起/唤醒 - 这些都不是运行时支持的协程——没有栈切换、没有调度策略、不解决阻塞问题
真要类比：C# 的 async 是“单线程异步编程模型”，不是“多协程协作调度系统”。它的复杂点在于状态机生命周期与 Task 状态转换耦合紧密，而最容易被忽略的是：所有 await 点都隐含调度决策，且这个决策受 SynchronizationContext 和 TaskScheduler 实际实现支配，不是代码字面能完全掌控的。
