STA/MTA 不是并发控制机制
很多人看到
Thread.ApartmentState就以为它能协调多线程访问共享资源，其实完全不是。它只影响 COM 对象的线程调度规则，和
lock、
ConcurrentQueue、
async/await这类真正的并发工具毫无关系。如果你在写纯 .NET 托管代码（没调用 COM 组件、没碰 WinForms/WPF 的 UI 控件），基本可以忽略这个属性。
什么时候必须设为 STA？
只有当你在线程里创建或调用以下对象时，.NET 运行时才强制要求该线程处于 STA 模式：
WinForms 的Control或
FormWPF 的
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<t></t>等托管对象无任何同步作用
真实并发场景下该怎么做？
如果你要从后台线程更新 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本身难得多。
