Thread.Priority仅影响线程调度权重，不提升执行速度；须在Running或WaitSleepJoin状态设置，启动前最稳妥；受进程PriorityClass约束，async/await中基本无效。
Thread.Priority 属性能设，但别指望它“让程序跑得更快”——它只影响线程在就绪队列里的调度权重，不改变单次执行速度，也不保证高优先级线程一定先跑完。
设置 Thread.Priority 前必须确认线程状态
你只能对 ThreadState.Running 或 ThreadState.WaitSleepJoin 状态的线程设置优先级。一旦线程进入 ThreadState.Stopped、ThreadState.Unstarted 或 ThreadState.Aborted，再赋值会抛 ThreadStateException。
- 启动前设置最稳妥：
thread.Priority = ThreadPriority.Highest;→thread.Start(); - 运行中修改可行，但 Windows 调度器可能延迟响应（尤其在负载高时）
- 主线程默认是
Normal，但 .NET 进程启动时继承自 OS，实际值可能被父进程或启动方式影响
ThreadPriority 枚举值的真实含义不是“快慢”，而是“抢 CPU 的激进程度”
5 个值对应 Windows 底层的 THREAD_PRIORITY_xxx 常量，最终映射到系统线程优先级类（如 REALTIME_PRIORITY_CLASS 下的相对偏移）。关键点：
-
Lowest和BelowNormal：适合日志归档、空闲扫描等后台任务，但别设Lowest做 I/O 等待型工作——它会让线程更难被唤醒 -
AboveNormal：UI 响应类操作常用，比如滚动列表时临时提权，避免卡顿 -
Highest：慎用。它可能饿死其他线程，尤其在单核 CPU 或长时间计算场景下；Windows 甚至会限制非特权进程使用Highest超过 15 秒 - 所有设置都受进程基础优先级类约束：
Process.GetCurrentProcess().PriorityClass是天花板，比如进程设为Idle，那即使线程设Highest，实际也只相当于Normal
async/await 场景下，Thread.Priority 基本无效
现代 C# 大量依赖线程池（ThreadPool）和 Task，而线程池线程本身不暴露 Priority 属性。你调用 Task.Run(() => { ... }, cancellationToken) 时：
- 底层从线程池取线程，该线程的
Priority已由 CLR 预设（通常是Normal），无法在Task启动时动态改 - 想提权？只能退回到显式创建
Thread+Start()，但失去 async/await 的可组合性 - 替代方案是用
DispatcherPriority（WPF）或SynchronizationContext控制 UI 更新时机，而非靠线程优先级抢资源
调试时怎么验证优先级真生效了？
别只看控制台输出顺序——那受缓冲、锁竞争、调度抖动干扰太大。可靠方法只有两个：
- 用 Windows 性能监视器（PerfMon）添加计数器：
Thread(*)\% Processor Time+Thread(*)\Priority Current，观察目标线程的实时优先级数值是否匹配预期 - 用 Process Explorer（Sysinternals 工具）打开进程 → Threads 标签页 → 右键线程 → Properties → Priority 字段，它显示的是 OS 级真实值（如 “13” 对应
Highestin NORMAL_PRIORITY_CLASS） - 注意：
Thread.Priority是逻辑值，GetThreadPriority返回的是 OS 层整数，二者映射关系取决于进程优先级类，不能直接比较
真正容易被忽略的点：线程优先级无法跨进程传递，也无法通过 async 上下文延续。你在一个 Task 里把当前线程提权，await 之后恢复的线程极大概率是另一个线程池线程，且优先级重置为默认。所谓“全局提权”，从来都得靠进程级 Process.PriorityClass 配合谨慎的线程粒度控制。
