为什么不能直接继承 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<task></task>如果调度策略复杂（如按优先级、延迟、分组），把决策逻辑前置到
StartNew外，
QueueTask只负责“投递”
最简可用骨架其实就三件事：维护一个消费线程/队列、在
QueueTask中入队、在消费者中循环
TryExecuteTask——其余都是围绕它加的约束和优化。
