我来帮你拆解这个遇到的问题：你在用Outlook Calendar API同步CRM用户日历的时候，碰到了同一个用户日历里出现两个Event ID完全相同的事件，一个是SeriesMaster类型，另一个是SingleInstance类型，这和我们通常认知的「事件ID应该全局唯一」似乎矛盾。

为什么会出现这种情况？ #

这其实是Outlook处理系列会议例外实例时的一个API边缘场景问题。当你对一个系列会议（由SeriesMaster代表）里的某一个具体实例做修改（比如改时间、换主题），Outlook会生成一个独立的例外实例（也就是SingleInstance类型）。但在特定的时间窗口查询时，这个例外实例的ID可能会被错误地返回成和系列主事件相同的ID——本质上是API返回的异常，正常情况下例外实例的SeriesMasterId应该指向原系列主事件的ID，但你提供的示例里第二个事件的SeriesMasterId是null，同时ID和主事件重复，这就是问题所在。

从你给出的示例细节也能看出差异：

• 第一个事件是重复会议的主模板：有完整的Recurrence规则，主题是"APPT"，Type为SeriesMaster
• 第二个事件是独立的单个实例：Recurrence为null，主题是"Alternate Health- Modern Business"，Type为SingleInstance，而且两者的iCalUId是完全不同的

怎么处理这个问题？ #

你可以通过以下几种方式来区分并处理这两个事件，避免CRM同步时出现冲突：

• 优先用Type字段区分：不管ID是否重复，SeriesMaster和SingleInstance的类型是明确的，直接通过Type就能判断哪个是系列主事件，哪个是单个实例
• 用iCalUId作为唯一标识：iCalUId是Outlook里真正全局唯一的会议标识，系列主事件和它的例外实例的iCalUId是不同的（你示例里两个事件的iCalUId确实不一样），所以可以依赖这个字段来做唯一判断，而不是Id
• 查询时过滤事件类型：调用API的时候，通过$filter参数过滤掉不需要的类型，比如只获取单个实例：

  GET /Users/{user-id}/Events?$filter=Type eq 'SingleInstance'
  

  或者只获取系列主事件：

  GET /Users/{user-id}/Events?$filter=Type eq 'SeriesMaster'
  

• 检查Recurrence属性：SeriesMaster一定会包含Recurrence规则，而SingleInstance的Recurrence必然是null，这也是一个快速区分的标志

总结 #

虽然事件ID重复看起来违反直觉，但这是Outlook API处理系列会议例外时的特殊场景，通过结合Type、iCalUId和Recurrence这几个字段，就能准确区分这两个事件，顺利完成CRM的日历同步工作。

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