必须加[STAThread]，否则调用Office自动化、OpenFileDialog等Windows原生COM组件会因线程模型不匹配而报RPC_E_WRONG_THREAD等错误，因这些组件依赖STA线程的消息泵和UI亲和性。
必须加 [STAThread]，否则 Office 自动化、OpenFileDialog 等 COM 组件直接报错
这不是可选项——只要你调用的是 Windows 原生 COM 对象（比如 Microsoft.Office.Interop.Excel、System.Windows.Forms.OpenFileDialog、Shell32.Shell），主线程就必须是 STA。.NET 默认不初始化 COM 线程模型，而这些组件内部依赖 Windows 消息泵（GetMessage/DispatchMessage）和 UI 线程亲和性，MTA 线程连创建实例都会失败，典型错误是：
-
RPC_E_WRONG_THREAD (0x8001010E)：最常见，表示跨线程调用未封送 COMException: 无法在具有不同线程模型的线程上执行操作- 程序卡死、无响应，尤其在 ShowDialog() 或 Visible = true 时
为什么 Main 方法加 [STAThread] 就够了？
因为 COM 初始化只发生在第一次调用 CoInitializeEx 时，而 [STAThread] 的本质就是在 Main 入口线程上调用 CoInitializeEx(COINIT_APARTMENTTHREADED)。它不是“装饰器”，而是运行时指令，影响整个进程的主线程 ApartmentState。
- 该属性只能放在
static void Main()上，放其他方法无效 - WPF 应用也必须加——哪怕你没写
Main，VS 模板生成的入口已默认包含 - 控制台应用如果只做纯计算、不碰 COM，可以不加；但只要调一次
OpenFileDialog.ShowDialog()，就必须加 - ASP.NET（.aspx）用
AspCompat="true"替代，但那是另一套上下文，不适用于桌面程序
Task.Run / 线程池里调 COM？绝对不行
Task.Run、ThreadPool.QueueUserWorkItem、new Thread(...).Start() 默认都在 MTA 线程上执行。你在里面 new Excel.Application()，会立刻抛异常或静默失败。
- 正确做法：显式创建 STA 线程，并手动泵消息（如果需要交互）
- 简单场景（如后台导出 Excel 不需 UI）：用
Thread.SetApartmentState(ApartmentState.STA)+thread.Start() - 复杂交互（如弹窗、处理事件）：还需在该线程里运行消息循环，例如
Application.Run(new Form())或手动GetMessage循环 - 更安全替代：用
Dispatcher.Invoke（WPF）或Control.Invoke（WinForms）把 COM 调用封送到 UI 线程
var thread = new Thread(() =>
{
var excel = new Microsoft.Office.Interop.Excel.Application();
excel.Visible = true;
// ... do work
excel.Quit();
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
thread.Join(); // 注意：Join 会阻塞，别在 UI 线程调用
容易被忽略的三个坑
-
异步回调陷阱：即使主线程是 STA，
async/await后续代码可能回到线程池线程（SynchronizationContext 丢失），导致 COM 调用崩在回调里 - 多 STA 线程共存：一个进程可以有多个 STA，但每个 STA 是独立消息队列；不要指望两个 STA 线程之间能直接共享 COM 对象引用
-
Office 进程残留：STA 线程退出前没调
Quit()+Marshal.ReleaseComObject()，Excel 进程常驻后台，下次启动可能因 COM 实例冲突失败
真正难的不是加那行 [STAThread]，而是识别哪些调用链最终会落到 COM 上——比如某封装库内部悄悄用了 Shell32，或日志组件调了剪贴板 API。一旦出现 RPC_E_WRONG_THREAD，第一反应不该是查 COM 版本，而是检查当前线程的 Thread.CurrentThread.GetApartmentState()。
