如何使用Microsoft Graph按标题和参会人邮箱搜索calendarView事件

之前查询报错/不生效的根因 #

• 带attendees/any(...contains(...))的filter报无效节点：calendarView 接口的contains操作符仅支持event实体的一级字符串字段（比如subject、bodyPreview），不支持对attendees这类集合导航属性的嵌套字段做模糊匹配，语法校验阶段就会被拦截。
• 把contains换成eq后报内部服务错误：calendarView 接口因为要展开周期性事件的所有实例，对attendees集合的any嵌套查询存在已知服务端bug，哪怕是精确eq匹配也会触发500错误，该问题在非展开的/me/events接口下部分租户可正常运行，但calendarView场景下不稳定，不建议生产使用。
• 传$search参数无过滤效果：calendarView 接口当前未实现$search参数的筛选逻辑，传入后服务端会直接忽略该参数，返回全量时间窗口内的事件，属于接口未支持的能力，不是参数写法错误。

可落地的实现方式 #

方式1：客户端二次筛选（实现成本最低，稳定性最高） #

适合查询时间窗口短、单用户事件量不大的场景：

1. 调用calendarView接口时，仅保留主题的contains筛选逻辑，同时通过$select指定返回必要字段，减少传输数据量：

   GET /me/calendarView?startDateTime={start}&endDateTime={end}&$filter=contains(subject,'<搜索词>')&$select=id,subject,start,end,attendees
   

2. 遍历接口返回的所有事件（记得处理@odata.nextLink翻页，拉全时间窗口内的全量数据），在本地对每个事件的attendees集合做匹配：
   • 检查是否有参会人的emailAddress.name（显示姓名）包含搜索词
   • 检查是否有参会人的emailAddress.address（邮箱地址）包含搜索词
3. 合并主题匹配、参会人字段匹配的事件，去重后就是最终搜索结果。

方式2：调用Microsoft Search API（原生服务端搜索，适合大数据量场景） #

如果时间窗口跨度大、事件量多，客户端筛选性能差，可以直接用Graph的统一搜索接口，原生支持多字段模糊匹配，行为和Google Calendar搜索对齐：

1. 发送POST请求到/search/query端点，请求体示例：

   {
     "requests": [
       {
         "entityTypes": ["event"],
         "query": {
           "queryString": "<搜索词> AND start>=2024-01-01T00:00:00 AND end<=2024-12-31T23:59:59"
         },
         "from": 0,
         "size": 50
       }
     ]
   }
   

2. 该接口的queryString遵循KQL语法，默认会匹配事件主题、正文、参会人姓名、参会人邮箱、会议位置等字段，不需要手动写多条件filter，返回结果直接是匹配完成的事件列表，支持分页。如果需要限定时间范围，直接在queryString里拼接start、end的时间条件即可，和calendarView的时间范围查询能力对齐。

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