知乎评论接口的offset参数是游标而非页码，须用上一页最后评论id字符串作下一次offset，首次请求应省略或传空字符串；需携带有效cookie、x-zse-86签名及合规user-agent，否则易触发反爬限制。
知乎评论接口的 offset 参数不是页码，而是起始评论ID
直接把 offset=20 理解成“第20条开始”是错的——知乎评论列表接口（如 /api/v4/questions/{qid}/answers 或 /api/v4/answers/{aid}/comments）实际用的是游标式分页（cursor-based），offset 字段名具有误导性，它本质是上一页最后一条评论的 id 值（字符串），而非整数偏移量。
常见错误现象：传入 offset=40 后返回空数组或重复数据；手动递增 offset 数值导致请求 400 或 401。
- 真实请求中必须携带上一页响应里的
data[-1]["id"]作为下一次的offset参数 - 首次请求时
offset应省略，或设为空字符串""（部分接口要求传"0"，需实测） - 注意响应里还可能带
is_end: true字段，比靠data长度判断更可靠
知乎反爬对 comment 接口的三重限制
即使参数正确，也大概率被拦截：IP限频、Cookie时效性、User-Agent指纹校验缺一不可。
- 必须复用登录态 Cookie（尤其是
z_c0和_xsrf），且有效期通常仅几小时；自动刷新需模拟登录流程或提取浏览器 localStorage 中的 token - 请求头必须包含
X-Zse-86（新版加密签名）和X-Zse-96（旧版已逐步弃用），缺失任一即 403；生成逻辑依赖时间戳、URL、设备 ID，无法硬编码 - 高频请求（如 time.sleep(1.5–3)，并用 requests.Session() 复用连接
绕过 offset 限制的替代方案：用 after 参数 + time 排序
部分评论接口（如回答下的评论流）支持 after + order_by 组合，比依赖 offset 更稳定。
例如请求：
GET /api/v4/answers/123456789/comments?limit=20&after=2024-05-12T08:12:34.123Z&order_by=created_time
-
after是 ISO 时间字符串，表示“获取此时间之后的评论”，可规避 ID 不连续问题 - 需先请求一次无
after的初始页，取data[0]["created_time"]作为下一轮起点 - 注意时区：知乎后端用 UTC，但前端显示为本地时间，解析
created_time时务必用datetime.fromisoformat(...).astimezone(timezone.utc)
其他平台（如小红书、B站）不适用 offset 模式
别套用知乎经验到别的平台——小红书评论接口用 cursor（base64 编码的游标字符串），B站用 next（纯数字页码），豆瓣甚至用 start/count 的传统 offset-limit。
关键差异点：
- 小红书的
cursor必须原样传递，解码后是 JSON，含时间戳和 ID，但修改会导致签名失效 - B站
next可递增，但超过总页数会返回空，且需配合ps（每页数量）使用 - 所有平台的评论接口都禁用未登录请求，且返回字段结构差异大，不能共用解析逻辑
真正麻烦的从来不是 offset 怎么填，而是每次换平台都要重抓请求链、重逆向签名、重处理字段映射。留个心眼：先抓包看响应结构，再写代码，别先写通用框架。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
