WPF+Prism(Unity)中COM服务同步实例化缓慢问题咨询

当你在WPF的UI线程（STA线程）同步实例化Microsoft.Office.Interop.Excel.Application时，Excel的COM服务器属于**单线程单元(STA)**模型。实例化过程中，Excel需要完成启动程序、加载组件、验证许可证、初始化相关服务等一系列操作，这些操作会直接阻塞当前的UI线程——因为STA线程要求所有与COM对象的交互都在同一线程执行，UI线程无法在等待Excel初始化的同时处理其他消息，所以会出现明显的7-8秒延迟。

而用Task.Run将实例化操作放到ThreadPool的MTA线程执行时，系统会自动为这个STA类型的COM对象创建一个独立的STA后台线程来托管它，UI线程不会被阻塞，只是等待Task完成（后台线程的初始化不占用UI线程资源，所以整体感知上速度更快）。

• STA COM对象的线程亲和性：Excel实例绑定在创建它的后台STA线程上，后续所有对该对象的调用必须在同一个线程上下文执行。如果直接在UI线程调用Excel的方法，会触发跨线程访问STA COM对象的异常，需要通过Dispatcher调度到对应线程，或者确保操作线程与创建线程一致。
• Unity容器的线程安全：Unity的RegisterInstance方法并非线程安全操作，虽然你用Wait确保了注册完成后再进行后续操作，但如果存在多个并发的容器注册操作，可能引发未知问题，建议确保容器注册串行执行。
• COM对象的资源回收：后台线程创建的COM对象更容易出现资源泄漏，导致Excel进程残留。需要显式调用Marshal.ReleaseComObject释放对象，或者在对象不再使用时触发GC回收，同时避免后台线程提前退出导致COM对象生命周期异常。
• 异常处理：Task.Run内部的异常会被包装成AggregateException在Wait时抛出，需要针对性捕获处理（比如Office未安装、权限不足、Excel启动失败等场景），避免未处理异常导致应用崩溃。
• 启动流程的影响：虽然当前方式比同步快，但Wait仍会阻塞UI线程直到Task完成。如果后续Excel初始化逻辑发生变化（比如耗时增加），可能再次影响应用启动速度，建议考虑将COM对象的初始化延迟到真正需要使用的时候，而非启动阶段。

内容的提问来源于stack exchange，提问作者EuroEager