使用HttpClient分页Microsoft Graph Users集合时@odata:nextLink的token过期适配问题

• @odata.nextLink（即翻页用的continuation地址）和之前的access token没有任何绑定关系
• 遍历途中遇到access token过期，只要拿到权限匹配的有效新token，直接用之前留存的nextLink地址发请求，就能无缝接着拉取后续数据，不需要从头重新遍历集合

底层逻辑 #

Graph API生成的@odata.nextLink本质是把当前翻页的位置游标、服务端临时查询快照直接编码到URL的查询参数里，本身就是一个独立的可直接调用的接口地址：

• 链接生成时不会嵌入原请求的access token，也不会和原token的会话做关联
• 服务端处理这类请求时，校验逻辑和初始列表接口完全一致：只校验请求头携带的access token是否有效、是否具备对应接口调用权限，同时校验URL里的nextLink参数是否合法未篡改，和生成这个nextLink时用的是哪个token没有关联

实际调用的注意事项 #

• 换token时不需要对nextLink的URL做任何修改，只需要把请求头里的Authorization字段值从旧token替换为新token即可，其余参数保持原样就能正常调用。这一点对不依赖Graph SDK、直接用HttpClient发请求的场景尤其友好，不需要额外维护SDK的内部状态机，只需要在请求拦截器层统一处理token过期的重试、换token逻辑即可
• 有两类失效场景和token完全无关，不需要误以为是token绑定导致的：
  • nextLink对应的服务端查询快照有默认有效期（通常约15分钟），如果两次翻页间隔过长，哪怕token完全有效，也会收到资源不存在类的错误
  • 手动篡改nextLink里的查询参数，导致服务端校验不通过
• 甚至不需要要求新换的access token和之前的token来自同一个租户主体，只要新token的权限范围覆盖对应接口的调用权限（比如调用Users集合需要User.Read.All这类权限），就能正常拉取nextLink指向的后续分页数据

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