c#调用com组件核心卡点是架构匹配、rcw手动释放和sta线程模型；32位com必须x86编译运行，注册须用对应架构regsvr32，引用后copy local=true，idispatch调用优先type.invokemember，主线程需[stathread]，后台线程须显式设sta，.net 6+需手动coinitializeex，office互操作须逐层releasecomobject。
直接上结论：C#调用COM组件不是“加个引用就能跑”，核心卡点在架构匹配、RCW生命周期管理和STA线程模型——这三处出错，90%的COMException和RPC_E_CALL_REJECTED就来了。
为什么Add Reference → COM里找不到你的DLL
不是VS没扫描到，而是注册或位数不匹配。32位COM组件在64位系统上必须用x86平台编译运行，AnyCPU + “首选32位”仍可能失败。
- 先确认注册：用对应架构的
regsvr32——32位DLL走%windir%\SysWOW64\regsvr32.exe，64位走%windir%\System32\regsvr32.exe - 再查CLSID：用
OLE/COM Object Viewer（OleView.exe）看注册表HKEY_CLASSES_ROOT\CLSID\{...}是否存在，且InprocServer32路径指向正确DLL - VS中添加引用后，检查生成的
Interop.YourLib.dll是否被复制到输出目录——Copy Local必须为True，否则运行时类型加载失败
Type.InvokeMember比dynamic更可靠
尤其当COM只暴露IDispatch（无强类型接口）时，dynamic在.NET Core/5+默认不支持，且无法控制调用上下文。
- 用
Type.InvokeMember显式传入BindingFlags，比如BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Instance - ref参数必须传
ref object，不能只传值；字符串建议先用Marshal.StringToBSTR转再传，避免SysFreeString引发内存异常 - 不要依赖GC回收RCW——
Marshal.ReleaseComObject必须手动调用，且需循环释放（返回值为0才真正释放）
[STAThread]不是装饰，是硬性要求
COM对象绝大多数要求单线程公寓（STA），主线程没标[STAThread]，或后台线程没显式设置，就会触发RPC_E_CALL_REJECTED。
- WinForms/WPF主入口必须有
[STAThread]；控制台程序也一样，否则Application类（如Office互操作）初始化即失败 - 后台线程调用COM前，必须用
Thread.SetApartmentState(ApartmentState.STA)并Start()，不能靠Task.Run隐式线程 - .NET 6+默认不自动调用
CoInitializeEx，需手动补：Marshal.ThrowExceptionForHR(Marshal.CoInitializeEx(IntPtr.Zero, 2))（2 = STA）
Office互操作的隐藏陷阱
Microsoft.Office.Interop.*看似封装友好，但实际是巨量RCW+进程外调用，稍不注意就残留Word进程或文件句柄锁死。
- 不用
wordApp.Quit()，而要用Marshal.ReleaseComObject逐层释放：para→wordDoc→wordApp，顺序反了会报错 -
SaveAs2的Filename参数必须是object类型，不能直接传string，否则部分版本抛ArgumentException - 调试时别开Word实例——Office会复用已有进程，导致
new Application()拿到的是旧实例，状态不可控
最易被忽略的一点：RCW释放不是“调一次就完事”。COM对象常通过多层包装暴露属性（比如Document.Paragraphs返回另一个COM对象），每层都得单独ReleaseComObject，漏一层，那个子对象就永远驻留内存。
