C#中无原生纤程，协程由async/await和IEnumerator模拟，运行于线程之上，协作式让出且无内核调度；线程由OS管理，可并行但开销大、需同步防护。
线程是操作系统内核调度的执行单元，纤程（Coroutine）在 C# 中不是原生概念，而是由语言和运行时（如 async/await、IEnumerator）模拟的用户态协作式执行流——它不对应 OS 线程，也不被内核调度。
线程由操作系统创建和管理，有独立栈和上下文
调用 new Thread(() => { ... }).Start() 会触发系统调用（如 Windows 的 CreateThread），分配约 1MB 栈空间（默认），并交由内核调度器决定何时运行、何时抢占。线程可并行（多核）或并发（单核时间片切换），但开销大、数量受限（几百个就可能耗尽内存或引发调度压力）。
常见错误现象：Thread.Abort() 已废弃，强行终止线程会导致资源泄漏或状态不一致；共享变量未加锁（lock / Interlocked）极易引发竞态。
- 每个线程有独立的
ThreadLocal存储 - 线程异常未捕获会直接终止整个线程，不传播到启动方
- 调试时可在 Visual Studio 的“线程”窗口中看到所有托管线程及其调用栈
C# 中没有“纤程”类型，只有协程模式的实现机制
所谓“纤程”在 C# 里实际指两类东西：IEnumerator（用于 yield return）和 Task（用于 async/await）。它们都运行在当前线程（通常是主线程或线程池线程）上，通过状态机（编译器生成的
容易混淆的点：Unity 的 StartCoroutine() 返回的是 Coroutine 对象，但它底层仍是基于 IEnumerator + 主循环驱动（每帧调用 MoveNext()），并非独立执行流。
-
yield return null让出控制权给同一线程的其他逻辑（如 UI 更新），不阻塞线程 -
await Task.Delay(100)不阻塞线程，而是注册回调，由SynchronizationContext或ThreadPool在时机成熟时继续执行 - 协程函数返回
IEnumerator或Task，本身不启动执行，需外部驱动（如while (enumerator.MoveNext())或await）
调度模型与错误处理完全不同
线程崩溃（未捕获异常）会终止该线程，但不影响其他线程；而协程中的异常会立即抛出到驱动它的上下文——比如 async void 方法中未捕获异常会直接导致进程崩溃（AppDomain.UnhandledException），这是最常踩的坑。
async void BadHandler()
{
await Task.Delay(100);
throw new InvalidOperationException("Boom"); // 进程级崩溃！
}
// 正确写法：async Task，由调用方 await 并处理异常
async Task GoodHandler()
{
await Task.Delay(100);
throw new InvalidOperationException("Boom"); // 可被 try/catch 捕获
}
- 线程间通信靠
Queue+Monitor或Channel
；协程间靠 TaskCompletionSource或事件回调 - 线程可设置优先级（
Thread.Priority），但协程完全无此概念——它的“时机”取决于状态机何时被调度执行 - 使用
ConfigureAwait(false)可避免协程回调强制回到原始上下文（如 UI 线程），提升性能并防止死锁
；协程间靠 不要试图在 C# 中“手动实现纤程调度器”
有人尝试用 Thread.Yield() + 循环 + 状态标记模拟纤程，这既无必要又危险：C# 的 async/await 编译器已为你生成高效状态机，且与 ThreadPool、SynchronizationContext 深度集成。手写调度器大概率破坏异步流的取消传播（CancellationToken）、超时控制和诊断能力（如 dotnet trace 无法识别自定义状态流转）。
真正需要区分的不是“线程 vs 纤程”，而是“是否需要并行执行”和“是否需要等待 I/O 而不阻塞线程”。前者选线程（或更现代的 Parallel / PLINQ），后者一律用 async/await。
