STA/MTA仅影响COM对象线程调度，与.NET并发控制无关；纯托管代码可忽略；仅创建WinForms/WPF控件或特定COM对象时需显式设为STA；MTA非更安全，并发应使用lock、ConcurrentQueue等机制。
STA/MTA 不是并发控制机制
很多人看到 Thread.ApartmentState 就以为它能协调多线程访问共享资源，其实完全不是。它只影响 COM 对象的线程调度规则，和 lock、ConcurrentQueue、async/await 这类真正的并发工具毫无关系。如果你在写纯 .NET 托管代码（没调用 COM 组件、没碰 WinForms/WPF 的 UI 控件），基本可以忽略这个属性。
什么时候必须设为 STA？
只有当你在线程里创建或调用以下对象时，.NET 运行时才强制要求该线程处于 STA 模式：
- WinForms 的
Control或Form - WPF 的
DispatcherObject（比如Window、TextBox） - 某些 COM 组件（如 Office 自动化对象：
Excel.Application、Word.Application）
典型错误现象：InvalidComObjectException 或 COMException 提示 “调用线程必须是 STA”；或者 WPF 线程上新建 Window 时直接抛 InvalidOperationException：“调用线程无法访问此对象，因为另一个线程拥有它”。
实操建议：
- 主线程默认是 STA（WinForms/WPF 应用启动时自动设置），不用改
- 手动创建新线程时，必须在
Start()前设thread.SetApartmentState(ApartmentState.STA) - 不能对已启动的线程调用
SetApartmentState，会抛InvalidOperationException -
Task.Run()启动的线程永远是 MTA，且不可更改——所以别指望用它来跑 UI 逻辑
MTA 是默认值，但不等于“更安全”或“更适合并发”
新线程默认是 MTA，但这只是告诉 COM：“这个线程可被多个 COM 对象共用，调用会由 COM 自己加锁调度”。它不会帮你同步 .NET 对象，也不会提升吞吐量。反而容易掩盖问题：比如你误在 MTA 线程里调用了 Excel COM 对象，可能暂时不报错（COM 内部做了封送），但性能极差、行为不可预测。
常见误区：
- 认为 MTA 线程天然支持并行调用 —— 错，COM 对象本身可能仍是单线程模型（如 Excel），MTA 只是让 COM 为你做跨线程封送（marshaling），代价很高
- 把
ApartmentState和线程池线程混为一谈 ——ThreadPool和TaskScheduler中的线程全是 MTA，且无法改为 STA - 试图用 STA 来“保护”普通字段 —— 完全无效，
ApartmentState对int、List等托管对象无任何同步作用
真实并发场景下该怎么做？
如果你要从后台线程更新 UI，正确路径是回到 UI 线程执行，而不是折腾线程的 ApartmentState：
if (control.InvokeRequired)
{
control.Invoke((MethodInvoker)delegate { control.Text = "done"; });
}
else
{
control.Text = "done";
}
对于纯计算型并发：
- 用
Parallel.For/Parallel.ForEach处理 CPU 密集任务 - 用
Task.Run+async/await跑 I/O 或长耗时操作 - 共享状态时，优先选
ConcurrentDictionary、Interlocked.Increment、lock，而不是依赖线程模型
COM 场景下真正关键的是：确保每个需要 STA 的 COM 对象只在**一个固定 STA 线程**中创建和调用；跨线程访问必须显式封送（比如用 Marshal.OleInitialize + Marshal.GetActiveObject 配合上下文切换），这点比设 ApartmentState 本身难得多。
