<p>C# 和 .NET 官方不支持纤程；所谓“Fiber”多为第三方用 unsafe、自定义调度器等模拟的协程，实际基于 Task/async-await，且存在兼容性、跨平台及稳定性问题。</p>
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。它虽不是纤程，但在绝大多数业务场景下能达到同等甚至更好的效果：
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
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 绑定去调度。纤程不是银弹，而是一个容易让你掉进寄存器和栈对齐陷阱的旧时代幽灵。
