应使用 Thread.CurrentThread.ManagedThreadId 而非已废弃且恒为0的 Id；ManagedThreadId 是 CLR 分配的稳定跨平台线程标识，但 async/await 后可能切换线程，需用 AsyncLocal 等逻辑上下文追踪。
直接用 Thread.CurrentThread.ManagedThreadId，别用 Thread.CurrentThread.Id —— 后者是操作系统线程 ID，在 .NET Core/.NET 5+ 上已废弃且返回 0。
为什么 Thread.CurrentThread.Id 总是 0？
.NET Framework 早期版本中 Id 确实返回 OS 线程 ID，但跨平台后语义模糊、不可靠。从 .NET Core 2.0 开始，Id 被标记为 obsolete，运行时始终返回 0（即使在 Windows 上），且不抛异常，容易误判。
-
ManagedThreadId是 CLR 分配的唯一整数，稳定、轻量、跨平台一致 -
Id底层调用的是Interop.Sys.GetThreadId()，但在非 Windows 平台无意义，故被“阉割” - 调试器（如 VS）显示的 “Thread ID” 列实际对应的是
ManagedThreadId，不是Id
调试时怎么快速打印当前线程信息？
别只打 ID，加点上下文更实用。比如：
Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] {Thread.CurrentThread.Name ?? "(unnamed)"} - {Thread.CurrentThread.IsThreadPoolThread}");
- 主线程默认
Name为空，建议启动时显式设：Thread.CurrentThread.Name = "Main" -
IsThreadPoolThread能立刻区分是 new Thread 还是 Task.Run / ThreadPool.QueueUserWorkItem 起的 - 避免在高并发日志里只写数字 ID —— 没有命名和类型标识，查日志时根本分不清哪个是 Timer 回调、哪个是 ASP.NET 请求线程
在异步方法（async/await）里还能用 CurrentThread 吗？
不能依赖 —— await 后可能切换线程，CurrentThread 值会变。常见错误是：
int tid = Thread.CurrentThread.ManagedThreadId; await Task.Delay(100); Console.WriteLine(tid == Thread.CurrentThread.ManagedThreadId); // 很可能输出 False
- 如果真要追踪逻辑上下文中的“同一线程”，改用
AsyncLocal<int>或CallContext.LogicalGetData（旧版） - ASP.NET Core 中更推荐用
HttpContext.TraceIdentifier或注入ILogger自动携带请求范围 ID - 不要在
async void方法里读CurrentThread做关键判断 —— 线程归属完全不可控
真正难的不是取 ID，而是理解什么时候它有意义、什么时候它已经失效。尤其在 async/await 和 ThreadPool 混用的场景下，ManagedThreadId 只反映“此刻”执行点的托管线程，不代表逻辑单元的生命周期。
