Graph API Skip Token在邮件删除场景的处理及异常问题咨询

首先得纠正一个关键误解：Graph API返回的数字skip token并不是代表要跳过的邮件数量，它是服务端生成的一个游标（cursor），用来标记当前分页在服务端邮件列表中的精确位置，这个位置和客户端本地计数的邮件数量没有直接对应关系——这是你遇到所有问题的核心根源。

旧Skip Token在邮件删除后的问题 #

当你存储了skip=100，然后用户删除了10封邮件，此时用skip=100请求服务端，服务端会跳过它内部标记的第100个位置的邮件，但因为前面的邮件被删除，服务端的邮件列表已经发生了偏移：原来的第100位邮件现在可能变成了第90位，而你请求的skip=100会直接跳过这部分邮件，导致你漏抓了中间的10封邮件，或者重复抓取后面的内容。

反向回溯修改Skip Token的方式是否合理？ #

这种方式非常不合理，原因很简单：skip token是服务端维护的状态，不是客户端可以随意加减的数字。你手动调整token本质是在猜测服务端的游标位置，而邮件列表是动态变化的（删除、新增、移动、标记已读等都会改变服务端的列表排序或内容），这种猜测很容易出错——这也是你出现半年邮件遗漏的主要原因之一，一旦某次回溯没找到正确的重叠点，后续所有分页都会偏离，导致大量邮件漏抓。

正确的处理方式 #

1. 完全依赖服务端返回的分页链接 #

绝对不要自己存储或修改skip参数，每次分页请求都必须使用上一次响应中的@odata.nextLink。这个链接包含了服务端生成的合法游标（可能是skip，也可能是其他形式的token），能确保你获取的是正确的下一页内容，不受邮件动态变化的影响。

2. 改用增量查询（Delta Query）同步邮件 #

如果你的场景是持续同步用户的收件箱，强烈推荐使用Graph API的增量查询，而不是普通的分页查询。增量查询会跟踪收件箱的所有变化（新增、删除、修改），返回一个@odata.deltaLink，后续用这个链接请求就能获取自上次同步以来的所有变化，不需要维护任何skip token，从根本上避免了邮件删除、新增导致的同步偏差。

解决你遇到的两个具体问题 #

• nextLink为null但收件箱仍有新邮件：
  普通分页的nextLink为null只代表服务端认为当前是最后一页，但之后有新邮件进来时，你需要重新发起第一页的请求（或者用增量查询的deltaLink）。另外检查你的请求参数，比如是否设置了时间范围过滤、文件夹过滤，导致新邮件不在查询范围内。
• 半年邮件遗漏：
  这几乎可以肯定是手动修改skip token导致的同步偏移。当邮件被删除后，客户端的skip计数和服务端的游标位置脱节，后续请求要么跳过了实际存在的邮件，要么重复抓取，最终导致大量邮件漏抓。改用增量查询可以彻底解决这个问题，它会遍历所有未同步的邮件，包括历史邮件和新增邮件。

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