C# 和 .NET 官方不支持纤程；所谓“Fiber”多为第三方用 unsafe、自定义调度器等模拟的协程，实际基于 Task/async-await，且存在兼容性、跨平台及稳定性问题。

C# 和 .NET 官方不支持纤程（Fiber）——这是最关键的事实。Windows API 虽然提供 ConvertThreadToFiber、SwitchToFiber 等原生纤程函数，但 .NET 运行时（包括 .NET 5/6/7/8/9）从未将纤程纳入托管调度模型，也未在 System.Threading 或任何 BCL 命名空间中暴露纤程抽象。

为什么你查到的“C# Fiber”大多来自第三方框架？

很多文章提到的 “FiberTaskScheduler”、“ET 框架 Fiber” 或 “Fiber 协程”，本质是开发者用 unsafe + StackGuard + 手动栈管理 + ExecutionContext 快照等黑科技，在用户态模拟纤程行为。它们不是 .NET 的一部分，而是对 Task / SynchronizationContext 的深度定制封装：

• ET 框架的 Fiber 是基于 OneThreadSynchronizationContext + 消息队列实现的逻辑纤程，实际仍跑在普通线程上，只是强制串行化执行
• FiberTaskScheduler_c# 类库依赖 P/Invoke 调用 Windows 纤程 API，但存在严重兼容问题：.NET Core/.NET 5+ 默认运行在 ThreadPool 线程上，而这些线程不允许被转为纤程（调用 ConvertThreadToFiber 会返回 NULL 或触发异常）
• 所有这类实现都无法跨平台（Linux/macOS 无 Win32 Fiber 支持），且与 async/await 的上下文捕获机制存在隐式冲突

那 C# 里真正该用什么替代纤程？

如果你追求的是“轻量、可挂起、高并发、单线程语义”的效果，.NET 官方路径非常明确：用 Task + async/await + 自定义 SynchronizationContext 或 TaskScheduler。它虽不是纤程，但在绝大多数业务场景下能达到同等甚至更好的效果：

• await 挂起时不会阻塞线程，调度开销远低于纤程切换（后者需保存/恢复寄存器 + 栈指针）
• Task 天然支持取消、超时、延续（.ContinueWith）、结构化异常传播，纤程模拟几乎无法完整复现
• ASP.NET Core 的请求处理、gRPC 服务端、SignalR Hub 方法，全部构建在 Task 基础上，而非纤程
• 若真需要极致可控的执行流（如游戏帧同步、高频状态机），可用 ValueTask + IAsyncStateMachine 手写状态机，比纤程更安全、更易调试

哪些错误会让你误以为“C# 支持纤程”？

常见误导来源和对应真相：

• 搜索 “C# fiber” 出现的博客标题含 FiberTaskScheduler_c# → 实际是 2013 年左右针对 .NET Framework 4.x 的实验性项目，已停止维护，不兼容 .NET 6+
• 看到 System.Threading.Fiber 类型 → 该类型根本不存在于任何 .NET SDK 中，是混淆了 Windows SDK 的 FIBER 结构体或某些私有 fork 的命名
• 用 unsafe 调用 SwitchToFiber 成功 → 只说明当前线程是手工创建的（非 ThreadPool），但一旦涉及 GC、JIT 内联、async 回调，极易引发栈损坏或 AccessViolationException
• ET 框架文档说 “Fiber = 协程” → 它的 Fiber 是一个语义概念封装，底层仍是 Task.Run + 队列 + 单线程循环，和 Windows Fiber 无任何关系

真正要上生产环境，别碰原生纤程。.NET 的异步模型已经足够健壮——问题往往不出在“不够轻”，而出在没理清 ConfigureAwait(false)、没约束好 Task.Run 的使用边界、或误把 I/O 绑定当 CPU 绑定去调度。纤程不是银弹，而是一个容易让你掉进寄存器和栈对齐陷阱的旧时代幽灵。