CoMarshalInterface与CoUnmarshalInterface为何需要REFIID及接口使用差异

问题1：CoMarshalInterface和CoUnmarshalInterface为何需要REFIID参数？ #

虽然这两个函数会优先查询对象的IMarshal接口（找不到则用默认COM封送实现），但REFIID参数的核心作用体现在三个方面：

• 明确封送的接口契约：封送的本质是跨进程/线程传递"接口代理"，REFIID告诉系统，客户端最终需要使用哪个接口与封送后的对象交互。默认封送器依赖这个ID来加载对应接口的类型信息（比如类型库），生成匹配的代理存根，确保后续调用的方法签名、参数传递符合接口定义。
• 兼容非规范的自定义IMarshal实现：虽然COM规范要求同一个对象的所有接口QueryInterface返回的IMarshal实例必须一致，但部分老组件或第三方组件可能实现了特殊逻辑——比如根据传入的REFIID调整封送内容（比如针对IDispatch只封送自动化方法，针对派生接口封送全部方法）。
• 类型安全校验：在CoUnmarshalInterface阶段，系统会校验最终返回的接口指针是否与传入的REFIID匹配，避免客户端拿到不符合预期的接口，减少类型错误。

问题2：使用IDispatch与最派生接口调用这些函数的区别？ #

从标准COM规范的角度，同一个对象无论用哪个接口调用CoMarshalInterface，最终QueryInterface得到的IMarshal都是同一个，理论上不会有差异，但实际场景中存在几个可能的例外：

• 非规范自定义IMarshal的特殊处理：部分组件的IMarshal实现可能会检查最初调用CoMarshalInterface时传入的接口指针（而非通过QueryInterface获取的IMarshal），针对IDispatch和派生接口执行不同的封送逻辑——比如某些老组件对IDispatch只做基础自动化封送，对派生接口则包含额外的非自动化方法的封送逻辑。
• 代理存根的生成差异：默认封送器需要对应接口的类型信息，如果最派生接口的类型库未正确标记与IDispatch的继承关系，或者类型库存在缺失，生成的代理存根可能与IDispatch的代理存根不同，导致跨进程调用时出现行为差异。
• Unmarshal后的接口直接返回：使用最派生接口的REFIID调用CoUnmarshalInterface时，系统会直接返回该接口的指针，无需客户端额外调用QueryInterface；而使用IDispatch的REFIID时，客户端拿到的是IDispatch指针，需要再执行QueryInterface转换。如果对象的代理在QueryInterface阶段有特殊逻辑（比如权限校验、懒加载），这一步转换可能带来不同的表现。

针对团队提到的"部分接口实现IMarshal存在问题"的场景：从COM规范来说，无论用哪个接口调用，QueryInterface都应该返回同一个IMarshal实例，但现实中存在非规范的组件实现，可能会依赖最初传入的接口ID做特殊处理，这种情况下就会出现差异。

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