Thread默认前台线程，主线程结束进程即终止，后台线程被强制中断；关键逻辑须Join()等待，辅助任务可设IsBackground=true；95%场景优先用Task.Run；共享变量需用Concurrent集合或lock保护；禁用Thread.Abort()，改用CancellationToken协作取消。
用 Thread 启动线程时为什么主线程一结束程序就退出了
因为 Thread 默认是前台线程（IsBackground = false），但如果你没显式 Join() 或等待它完成，主线程跑完 Main 方法后进程直接终止，后台线程会被强制中断——哪怕它还在跑。
实操建议：
- 确认线程用途：如果是长期运行的辅助任务（比如监听、轮询），设为后台线程：
thread.IsBackground = true - 如果是关键业务逻辑（比如上传完成才退出），必须调用
thread.Join()等待结束，或改用Task+await - 别依赖
Thread.Sleep(1000)模拟“等一会儿”，这不保证线程真执行完了，只是碰运气
Task.Run 和 new Thread(...).Start() 选哪个
Task.Run 基于线程池，启动快、开销小、能自然配合 async/await；Thread 是独占系统线程，适合长时间独占 CPU 或需要精确控制生命周期的场景（比如实时音频处理）。
常见错误现象：用 Thread 频繁创建短任务 → 线程创建销毁开销大，CPU 上下文切换频繁，性能反而比 Task.Run 差好几倍。
实操建议：
- 95% 的并发场景用
Task.Run，尤其涉及 I/O 或短计算 - 需要设置线程名称、优先级、或隔离栈空间时，才考虑
Thread -
Task.Run(() => { /* 耗时同步代码 */ })是安全的；但别在Task.Run里又开Thread，纯属叠床架屋
线程间共享变量导致结果错乱怎么办
多个线程同时读写同一个 int、List<T> 或自定义对象字段，不加防护就会出现脏读、丢失更新、甚至 NullReferenceException——这不是偶发 Bug，是必然发生，只是时机不确定。
实操建议：
- 优先用线程安全类型：
ConcurrentQueue<T>、ConcurrentDictionary<K,V>、Interlocked.Increment(ref count) - 避免锁整个方法，只锁真正共享的临界区；别用
lock(this)或lock(typeof(MyClass))，容易引发死锁或意外争用 - 如果只是读多写少，考虑
ReaderWriterLockSlim，比普通lock更高效
调试时看到 ThreadAbortException 或 “无法访问已释放的对象”
Thread.Abort() 在 .NET Core/.NET 5+ 已被彻底移除，但旧项目迁移后若还调用它，会抛出 PlatformNotSupportedException；而“无法访问已释放的对象”往往是因为线程还在用某个 IDisposable 对象（比如 FileStream），但主线程已经把它 Dispose() 了。
实操建议：
- 永远不要调用
Thread.Abort()，改用协作式取消：CancellationToken+token.ThrowIfCancellationRequested() - 所有跨线程使用的资源，确保生命周期由持有者统一管理；必要时用
using块包住整个线程逻辑 - 调试时注意线程名和 ID：
Thread.CurrentThread.Name和Thread.CurrentThread.ManagedThreadId，能快速定位是哪个线程在误操作
线程安全不是靠“大概不会出事”来保障的，而是每一处共享、每一次等待、每一个 Dispose 都得有明确归属。很多人卡在“本地跑得好好的，上线就崩”，问题往往出在时间差和竞争窗口——这些地方没法靠日志一眼看出，得从设计上堵死。
