GraphQL分页常见结构通过响应中是否存在pageInfo、endCursor、hasNextPage等字段识别，若有则属Relay游标分页，需用after参数翻页；否则可能为offset分页。
GraphQL分页常见结构怎么识别？
GraphQL本身不规定分页格式，但实际接口基本逃不开 first/after（Relay规范）或 limit/offset（简单游标或偏移）。抓取前必须先看文档或试发一次查询，确认返回里有没有 pageInfo、endCursor、hasNextPage 这类字段——它们才是翻页的关键信号，不是靠猜页码。
- 如果响应里有
pageInfo.hasNextPage === true且pageInfo.endCursor非空，说明用的是 Relay 游标分页，下一页必须传after: "xxx" - 如果只有
totalCount和data数组，但没游标字段，大概率是服务端偷偷做了 offset 分页，这时得手动累加offset参数 - 别直接信响应里的
pageInfo.hasNextPage值：有些接口在最后一页仍返回true，但下一次请求返回空数据，得靠data长度是否为 0 来双重判断
requests发GraphQL查询时怎么带分页参数？
GraphQL 请求本质是 POST JSON，分页参数就塞在 variables 字段里，不是 URL 查询参数。写错位置（比如拼到 URL 上）会导致参数被忽略，永远只拿第一页。
- 构造 payload 时，确保
query字符串里有占位符，例如$first和$after，并在variables对象里对应传值 - 第一次请求
variables可设为{"first": 10}；拿到响应后提取data.xxx.edges[0].cursor或pageInfo.endCursor，作为下次的after值 - 注意字符串转义：
after值通常是 base64 编码的，直接原样传，别再 encode 一遍，否则服务端解不出
{
"query": "query($first: Int!, $after: String) { users(first: $first, after: $after) { edges { node { id name } } pageInfo { hasNextPage endCursor } } }",
"variables": {"first": 10, "after": "YXJyYXljb25uZWN0aW9uOjEw"}
}
清洗分页数据时最容易漏掉什么？
分页拉下来的数据是嵌套结构（尤其 Relay 规范），直接 flatten 容易丢节点或重复。关键不是“把所有 node 提出来”，而是保持每页上下文可追溯。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 不要直接对
response["data"]["users"]["edges"]循环取node就完事：检查是否有cursor字段，它可能和业务逻辑强相关（比如用于去重或排序锚点） - 如果多页数据要合并成一张表，先统一字段名：有些页的
node里是fullName，另一页却是name+lastName，得提前映射好 - 空数据页也要记录：某次请求返回
{"data": {"users": {"edges": []}}}，不代表出错，可能是真没数据，但得留日志，否则后续分析会误判总量
异步并发拉取 GraphQL 分页会踩哪些坑？
用 asyncio + aiohttp 能提速，但 GraphQL 接口往往限流严格，且游标依赖上一页结果，不能真正“并行”。
立即学习“Python免费学习笔记（深入）”；
- 绝对不要并发请求第 2、3、4 页：因为第 2 页的
after值来自第 1 页响应，没拿到就发第 2 页，必然失败 - 可以并发的是“同一页内多个子查询”（比如拉完用户列表后，并发查每个用户的 profile），但主分页流必须串行
- 加
sleep(0.1)比硬扛 429 更稳妥：有些接口对游标请求频率敏感，连续毫秒级请求容易触发限流，返回"rate limit exceeded"错误
真正难的不是写循环，是判断什么时候该停——hasNextPage 是软信号，edges 为空才是硬终点。别省那一次请求。
