ContinueWith 在前序 Task 进入 IsCompleted 状态（含 IsFaulted/IsCanceled）即触发，非仅成功完成；应显式用 OnlyOnRanToCompletion 过滤，并避免直接访问 Result；await 更可靠因其绑定上下文、自动处理异常且语义明确。
Task.ContinueWith 为什么有时不按预期执行
延续任务不是“等前一个完再跑”，而是“前一个进入 IsCompleted 状态就触发”——包括 IsFaulted 或 IsCanceled。很多人只测试了正常完成路径，结果上线后异常时延续任务照样跑，逻辑错乱。
- 显式指定
TaskContinuationOptions：用TaskContinuationOptions.OnlyOnRanToCompletion过滤掉失败/取消场景 - 避免在延续任务里直接访问前序
Task.Result，它可能抛出AggregateException；改用task.Exception判断或用await更安全 -
ContinueWith默认调度到线程池，UI 线程需传TaskScheduler.FromCurrentSynchronizationContext()
await + async 比 ContinueWith 更可靠吗
是的，但不是因为“更高级”，而是因为 await 天然绑定执行上下文、自动展开异常、且语义明确：它等的是“可等待对象完成”，不是某个 Task 实例的状态变化。
-
await后的代码一定在前序完成后才执行（无论成功/失败），而ContinueWith的回调函数本身可能被调度延迟 - 多个
await链天然串行，不用手动传Task引用；ContinueWith容易因闭包捕获错误变量导致状态混乱 - 注意：如果前序
Task是void返回的 async 方法（即 fire-and-forget），await就没法用了——这种场景才被迫回到ContinueWith
Task.Run 后接 ContinueWith 为什么总在后台线程执行
因为 Task.Run 默认用线程池调度，它的延续任务也继承这个默认调度器，除非你显式指定。
- 想回到 UI 线程？传
TaskScheduler.FromCurrentSynchronizationContext()，但确保调用时上下文非 null（比如 WinForms/WPF 主线程中） - 想控制并发？用
Task.Factory.StartNew(..., new TaskCreationOptions { PreferFairness = true })，但别指望它保证顺序——公平性 ≠ 执行顺序 - 不要依赖线程 ID 或
Thread.CurrentThread做逻辑分支，Task 调度层抽象掉了线程细节
多个 Task 怎么按固定顺序串行执行（非 await 场景）
真要绕过 await 写纯 ContinueWith 链，核心是把上一个延续任务的返回值作为下一个的输入，并确保每个环节都返回 Task。
var t1 = Task.Run(() => DoStep1()); var t2 = t1.ContinueWith(_ => DoStep2(), TaskContinuationOptions.OnlyOnRanToCompletion); var t3 = t2.ContinueWith(_ => DoStep3(), TaskContinuationOptions.OnlyOnRanToCompletion); // 注意：t3 是 Task<Task>，得 .Unwrap() 才变成 Task t3.Unwrap().Wait();
- 每级
ContinueWith返回的都是新Task，嵌套多了容易漏Unwrap或Result访问异常 - 一旦某步返回
Task（比如又调了Task.Run），必须用Unwrap展平，否则后续ContinueWith会接到Task<task></task> - 这种写法调试困难，堆栈里全是
TaskScheduler内部帧；生产环境优先走async/await
最常被忽略的一点：Task 的“顺序”本质是数据依赖，不是时间先后。哪怕你用 ContinueWith 强制串行，如果前序任务内部有异步 I/O 或未 await 的子任务，外部看到的完成顺序依然可能错乱——得一层层检查到底层是否真正阻塞或等待了。
