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回调，极易引发栈损坏或
AccessViolationExceptionET 框架文档说 “Fiber = 协程” → 它的
Fiber是一个语义概念封装，底层仍是
Task.Run+ 队列 + 单线程循环，和 Windows Fiber 无任何关系
真正要上生产环境，别碰原生纤程。.NET 的异步模型已经足够健壮——问题往往不出在“不够轻”，而出在没理清
ConfigureAwait(false)、没约束好
Task.Run的使用边界、或误把 I/O 绑定当 CPU 绑定去调度。纤程不是银弹，而是一个容易让你掉进寄存器和栈对齐陷阱的旧时代幽灵。
