同一机器上.NET(C#) Office插件实例间复杂对象传递最优方案

我之前也处理过类似的Office插件跨实例通信场景，先给你梳理下可行的方案，再说说各自的优劣，帮你判断哪个最适合你的情况：

• 命名管道（Named Pipes）：这确实是个非常靠谱的选择，尤其适配同一台机器上的进程间通信（IPC）场景。.NET自带的System.IO.Pipes命名空间可以直接上手，支持双向通信，针对复杂对象的传递，你可以结合序列化来处理——推荐用System.Text.Json（安全且易用），或者如果追求性能可以用Protobuf（Google.Protobuf NuGet包）。实现逻辑也清晰：一个插件实例作为服务端监听指定命名管道，另一个作为客户端发起连接，序列化对象后发送，接收端反序列化还原即可。需要注意的是要处理好连接异常、断开重连这些细节，但对于Word/Excel各自独立的插件实例来说，逻辑不会太复杂，整体是性价比很高的方案。

• 共享内存（Shared Memory）：如果你的对象体积特别大、对通信性能要求极致，这个方案可以考虑。.NET里通过MemoryMappedFile类实现，把对象序列化后写入共享内存区域，另一个实例读取后反序列化。但这个方案复杂度高，需要自己处理同步（比如用Mutex互斥锁避免读写冲突）、内存区域的生命周期管理，调试起来也更麻烦，除非有硬性性能要求，不然一般不优先选。

• Windows消息（Windows Messages）：这个方案更适合传递简单数据，复杂对象传递会非常棘手。因为Windows消息的参数只能是整数或指针，要传复杂对象得先序列化到非托管内存，再把内存地址发过去，接收端再读取。这种方式涉及到Marshal类的非托管操作，风险较高（比如内存泄漏、无效地址访问），而且Office插件的进程模型可能带来额外限制，完全不推荐用来传复杂对象。

• 本地文件/注册表：把对象序列化后写到临时文件或注册表项，另一个实例读取后清理。这个方案实现最简单，但缺点也很突出：有文件IO开销、性能差，并发场景下容易出现读写冲突，还可能留下临时文件残留，适合临时应急，绝非长期最优解。

总结 #

回到你的场景，命名管道绝对是最优选择——它平衡了实现复杂度、性能和可靠性，完全能满足跨Office插件实例传递复杂对象的需求。如果担心序列化效率，换成Protobuf序列化会比JSON更高效，适配复杂对象的传递场景。

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