最稳方式是用Thread.CurrentThread.ManagedThreadId获取当前线程ID，它返回int类型；Thread.CurrentThread.Id根本不存在，编译报错CS1061；Process.GetCurrentProcess().Id是进程ID，非线程ID。
怎么拿到当前线程的 ID
直接用 Thread.CurrentThread.ManagedThreadId，这是最稳、最轻量的方式。它返回一个 int，不是字符串也不是 GUID，别去调 Thread.CurrentThread.Id——那个是只读属性但**根本不存在**，C# 里压根没这个成员，IDE 自动补全有时会骗人。
常见错误现象：Thread.CurrentThread.Id 编译报错 CS1061；或者误用 Process.GetCurrentProcess().Id，拿的是进程 ID，完全不是线程。
- 只在需要区分逻辑线程时才取 ID，比如日志打标、调试追踪
- 不要用它做线程同步依据（ID 可能复用），更不能存起来长期比对
- 在
async/await后可能切换线程，ManagedThreadId会变——这点特别容易被忽略
为什么 ThreadStatic 变量在线程间不共享
因为 [ThreadStatic] 是编译器和 CLR 联合保障的隔离机制：每个线程一份独立副本，初始化为默认值（0、null 等），不走任何构造或赋值传播。
使用场景：缓存线程本地计算结果、避免锁、实现无锁上下文（如 ASP.NET 的 HttpContext.Current 旧实现）。
- 必须加
static修饰符，否则无效 - 不能用于实例字段，也不能用在属性上（只支持字段）
- 在 ThreadPool 线程或 async 方法里，新线程看不到旧值，也不会自动继承——得自己显式初始化
- 注意内存泄漏：如果存了大对象且线程长期存活（比如自建线程池），记得适时清空
Task.Run 里拿不到原始线程 ID 怎么办
因为 Task.Run 默认调度到线程池，执行线程不确定，ManagedThreadId 和发起线程必然不同。想保留上下文，得靠 AsyncLocal<T> 或显式传参。
性能影响：频繁创建 AsyncLocal 实例开销不大，但它的值会随 async 方法栈自动流动，比 ThreadStatic 更适合异步场景。
- 别在
Task.Run里试图“捕获”外层线程 ID 并塞进变量传递——容易出竞态 - 若真要关联，用
AsyncLocal<int>存 ID，在入口处赋值，后续 await 链里都能读 - 注意
AsyncLocal的Value在 await 后可能为 null，初始化逻辑要写在读取前 - 不要把它当全局状态容器，生命周期和 async 上下文绑定，退出后自动清理
调试时怎么看多个线程正在执行哪段代码
Visual Studio 调试器的「并行堆栈」窗口（Debug → Windows → Parallel Stacks）是唯一靠谱方式。它不依赖日志，实时展示每个线程的调用栈、是否阻塞、是否在 await 中挂起。
容易踩的坑：只看「线程」窗口看到的是 OS 线程 ID，和 ManagedThreadId 不一致；而输出日志里的线程 ID 如果没加锁或没用 ConcurrentQueue 写入，顺序会乱，无法对应真实执行流。
- 启用「显示任务」模式（右上角切换），能看到 Task 状态（Running/WaitingForActivation/…）
- 鼠标悬停在线程节点上，会显示其
ManagedThreadId，和代码里打印的一致 - 遇到死锁？优先看哪些线程卡在
Wait()、Result或GetAwaiter().GetResult() - Release 模式下调试信息可能缺失，确保 PDB 已生成且加载
线程 ID 本身只是个整数，真正难的是理清数据在哪个上下文里被修改、谁持有锁、await 是否真的释放了线程——这些没法靠 ID 推出来，得结合堆栈和变量视图一起看。
