不能直接继承 TaskScheduler 后就用，因为必须实现 protected abstract 的 QueueTask 方法，且若不重写 GetScheduledTasks，则并行任务窗口无法显示任务；QueueTask 中须将 Task 入队并启动消费，最终调用 TryExecuteTask 或 TryExecuteTaskInline 执行，否则任务卡在 WaitingToRun 状态。
为什么不能直接继承 TaskScheduler 后就用？
因为 TaskScheduler 是抽象类，但关键的 QueueTask 方法是 protected abstract，你必须实现它；而更隐蔽的问题是：如果没重写 GetScheduledTasks（用于调试和诊断），在 Visual Studio 的并行任务窗口里看不到你的任务，排查时会误以为任务没提交成功。
常见错误现象：Task.Run(..., yourCustomScheduler) 看似执行了，但断点不进、日志不打、线程卡住——大概率是 QueueTask 里没真正触发执行逻辑，或忘了调用 TryExecuteTask。
- 必须确保
QueueTask内部把Task放入你控制的队列，并启动消费（比如用Thread.Start或ThreadPool.UnsafeQueueUserWorkItem） - 每个被调度的
Task最终必须由base.TryExecuteTask(task)或TryExecuteTaskInline触发运行，否则它永远处于WaitingToRun状态 - 不要在
QueueTask中同步执行task——这会破坏调度语义，且导致Task.Wait()死锁
TaskScheduler 和 SynchronizationContext 的关系容易被忽略
自定义 TaskScheduler 不会自动影响 await 的上下文捕获行为。如果你期望 await 后回到某个 UI 线程或特定线程，仅靠替换 TaskScheduler 是不够的——await 默认绑定的是当前 SynchronizationContext，不是 TaskScheduler。
使用场景：你想做一个“单线程 UI 调度器”模拟 WinForms 的 Control.Invoke 行为。这时候你要：
- 在
QueueTask中把Taskpost 到目标线程（如用BeginInvoke） - 同时在该线程首次进入时，用
SynchronizationContext.SetSynchronizationContext(new YourSyncContext())替换上下文 - 否则
await task.ConfigureAwait(true)仍会尝试捕获空上下文，回不到你的线程
如何安全地实现线程内联（inline execution）？
TryExecuteTaskInline 是可选重写的，但它决定是否允许任务在 Task.Start() 或 ContinueWith 当前线程直接运行。不实现它，所有内联请求都会失败；实现不当，会导致栈溢出或死锁。
典型错误：在 UI 线程调度器里无条件返回 true 并直接调用 TryExecuteTask，结果 await 链反复内联，最终爆栈。
- 只在当前线程“属于该调度器管辖范围”时才返回
true（例如：检查Thread.CurrentThread == _uiThread） - 内联执行前务必确认任务状态是
WaitingToRun，避免重复执行 - 不要在
TryExecuteTaskInline里再调用QueueTask，这是循环入口
示例判断逻辑：
protected override bool TryExecuteTaskInline(Task task, bool taskWasPreviouslyQueued) {
if (Thread.CurrentThread != _targetThread || task.Status != TaskStatus.WaitingToRun) return false;
return TryExecuteTask(task);
}
性能陷阱：别在 QueueTask 里做耗时操作
Task.Factory.StartNew 或 Task.Run 调用你的 QueueTask 时，期望它是 O(1) 快速返回的。如果里面包含文件读写、网络等待、锁竞争或复杂对象构造，会拖慢整个任务提交链路，甚至让 Parallel.For 类操作降级为串行。
真实踩坑案例：有人在 QueueTask 中记录日志到磁盘，结果并发 1000 个任务时，线程池饥饿，CPU 占用低但响应极慢。
- 日志、监控、统计等副作用应异步化（例如用
ThreadPool.QueueUserWorkItem单独处理） - 避免在
QueueTask中持有长生命周期锁；如需排队控制，用无锁结构如ConcurrentQueue - 如果调度策略复杂（如按优先级、延迟、分组），把决策逻辑前置到
StartNew外，QueueTask只负责“投递”
最简可用骨架其实就三件事：维护一个消费线程/队列、在 QueueTask 中入队、在消费者中循环 TryExecuteTask——其余都是围绕它加的约束和优化。
