thread类在c#中虽可用但不推荐：start()后线程“消失”常因主线程过早退出，需join()等待；parameterizedthreadstart仅支持单object参数，应封装record传参；abort/suspend/resume已移除，改用cancellationtoken；isbackground=true不自动释放资源；异常需手动捕获，而task天然支持错误隔离。
Thread 类在 C# 中仍可用，但不推荐用于新项目——它属于低层线程控制，容易出错、难维护，且 .NET 早已转向 Task 和 async/await。如果你必须用 Thread（比如维护旧代码、嵌入式场景或需精确控制线程生命周期），下面这些点直接决定你能不能跑通、会不会卡死、上线后会不会半夜被报警叫醒。
为什么 Start() 后线程立刻“消失”或没输出？
最常见原因是主线程退出太快，导致进程终止，后台线程被强制回收（即使你没设 IsBackground = true，默认也是前台线程，但若主线程已 Main() 返回，整个进程就结束了）。
- 必须显式等待：调用
thread.Join()阻塞主线程，直到子线程完成 - 不要只靠
Console.Read()或Thread.Sleep()—— 它们不可靠，尤其在 Release 模式或高负载下 - 如果不想阻塞，至少确保主线程存活足够久，例如用
AutoResetEvent或ManualResetEvent同步
传参只能是 object？那怎么传多个或强类型参数？
ParameterizedThreadStart 委托只接受一个 object 参数，这是硬限制。强行传数组或匿名类虽能编译，但易引发类型转换错误或 GC 压力。
- 推荐做法：封装成自定义类或 record，再强制转换，例如
thread.Start(new WorkContext { Id = 123, Name = "test" }) - 避免用
dynamic或object[]—— 运行时类型检查缺失，调试困难 - lambda 表达式写法（如
new Thread(() => DoWork(arg1, arg2))）看似绕过限制，实则捕获的是闭包变量，要注意变量生命周期 —— 若主线程改了arg1，子线程看到的可能是新值
Abort()、Suspend()、Resume() 为什么一用就报错？
这些方法从 .NET Framework 2.0 起就被标记为 [Obsolete]，在 .NET Core / .NET 5+ 中**完全移除**。试图调用会编译失败或运行时报 PlatformNotSupportedException。
-
Abort()曾用异常中断线程，但可能破坏锁状态、资源未释放，极不安全 -
Suspend()/Resume()易造成死锁（比如挂起时正持有锁），且无法跨线程安全协调 - 替代方案：用
CancellationToken+ 循环中轮询token.IsCancellationRequested，配合thread.Interrupt()（仅唤醒 Sleep/Wait 状态）
IsBackground = true 是万能“保命符”吗？
设为后台线程确实能让进程退出时不等它，但它**不会自动清理资源**——文件句柄、数据库连接、未释放的 IDisposable 对象照常泄漏。
- 后台线程适合做纯计算、日志刷盘、心跳上报等“可丢弃”任务
- 涉及 I/O、锁、外部资源时，必须自己实现优雅退出逻辑（例如监听取消信号 + 手动释放）
- 别依赖“后台线程会随进程干净结束”——Windows 上可能残留句柄，Linux 上可能触发 SIGKILL 导致
finally不执行
真正麻烦的从来不是“怎么启动线程”，而是“怎么让它安全开始、可控运行、可靠结束”。Thread 类把所有责任都甩给开发者，连异常捕获都要手动在入口方法包一层 try/catch，否则未处理异常会让整个进程崩溃。现在用 Task.Run()，异常会存到 Task.Exception，还能用 await 自动传播——这不是语法糖，是错误隔离机制的代差。
