Microsoft Graph delta查询组增量变更的接口差异与使用问题

两个接口的核心差异 #

除了你观察到的已删除用户条目差异，两者核心区别有4点：

• 接口设计目标完全不同
  https://graph.microsoft.com/v1.0/groups/[group-id]/transitiveMembers 是实时全量查询接口，返回请求发起瞬间组内当前生效的所有传递成员，直接过滤掉已删除、已移除的对象，适合临时查询当前成员列表的场景。
  /groups/delta 是增量同步接口，设计目的是帮客户端做本地存储和云端目录数据的增量对齐，不是用来查询实时全量状态的。
• 成员返回逻辑不同
  transitiveMembers 只返回当前有效成员，不会输出任何已经从组内移除、或者本身被软删除的对象。
  而delta接口返回的members@delta是指定时间窗口内所有和组成员关系发生过关联的对象——不管对象现在是不是还在组里，哪怕是加入后又被移除、或者对象本身被删除，只要在同步窗口期有过变更，都会出现在结果里，用来告知客户端该对象的状态变化。
• 成员覆盖范围不同
  transitiveMembers 默认返回所有层级嵌套组下的传递成员，包含用户、设备、其他组等所有目录对象类型。
  你当前delta查询取的members@delta属性，仅跟踪组的直接成员变更，完全不包含嵌套组内的传递成员，这也是两边结果对不上的常见原因。如果要跟踪传递成员的增量，需要查询transitiveMembers@delta属性。
• 结果有效性规则不同
  你第一次调用delta接口拿到的只是第一页的变更片段，不是最终结果：delta分页过程中同一个对象的状态可能在不同分页更新，后页的状态会覆盖前页，必须把所有带@odata.nextLink的分页全部请求完，把所有分页里的members@delta条目按规则合并（遇到带@removed标记的条目就删除对应id的成员），最终得到的当前有效成员列表才是准确的。你现在看到第一页多出来的id2、id3，本质是还没翻完所有分页时的中间状态数据。

关于@odata.deltaLink的使用问题 #

不能直接用这个地址获取目标组的后续增量变更，原因很明确：

• 你当前调用的是租户级的组delta接口，只是加了id eq '[group-id]'的过滤条件，最终拿到的@odata.deltaLink是绑定整个租户的组列表的，后续调用这个地址会返回租户下所有组的增量变更，不是只返回你指定的单个组的数据，不仅会拉到大量无关数据，还要求你的应用拥有全租户组的读取权限，权限范围也不匹配。
• 就算你接受每次拉全租户数据再自己过滤目标组，当前delta查询跟踪的是members@delta（仅直接成员），和你一开始查询的transitiveMembers（含传递成员）的范围不一致，后续拿不到嵌套组成员的变更，数据会不全。

如果要正确跟踪单个组的传递成员增量，正确的初始查询应该用单个组的delta端点：https://graph.microsoft.com/v1.0/groups/[group-id]/delta?$select=id,transitiveMembers@delta，等翻完所有nextLink拿到对应这个组的deltaLink之后，再调用对应地址，才会只返回这个组的传递成员后续增量变更。

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