评论翻页需用响应中的next/cursor字段而非递增page；时间戳须校准服务器时间且注意时区；signature多为HMAC-SHA256加密，密钥常藏于JS中；还需模拟真实行为链，包括请求间隔、UA、Referer及headers顺序。
评论接口翻页参数不是简单 page=1、page=2
很多网站的评论接口看似用 page 或 offset 控制翻页，实际请求里藏着动态生成的 cursor 或 next 字段，它往往是一串 base64 编码的时间戳+ID 拼接体，比如 MTIzNDU2Nzg5MHx1c2VyX2FhYWFhYQ==。直接递增数字会返回 {"code":400,"msg":"invalid cursor"}。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 抓包时重点看响应 body 里的
next、cursor、max_id字段，不是看 URL 参数 - 用 Python 的
base64.b64decode()解码试试，常能看见明文时间戳（如1712345678900）和评论 ID - 翻页时不要自己拼 offset，而是把上一页响应里的
next值原样带入下一次请求的params
时间戳不是 int(time.time() * 1000) 就完事
有些接口要求时间戳对齐服务端时钟，误差超过 30 秒就拒绝；更常见的是，时间戳被嵌进加密流程——比如作为 AES 加密的 IV，或参与签名哈希计算。单纯用本地时间生成，哪怕毫秒级精准，也会触发 {"code":403,"msg":"signature invalid"}。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 先从首页 HTML 或 JS 文件里搜
new Date()、Date.now()、timestamp，看前端是否从服务端接口拉取过校准时间（如/api/time） - 如果没公开校准接口，可临时用响应头
Date字段反推服务器时间：用response.headers.get('Date')解析成 datetime，再转毫秒时间戳 - 注意时区：JS 的
Date.now()是本地时区毫秒数，但后端通常按 UTC 处理，差 8 小时很常见
Signature 通常不是单次哈希，而是多步拼接+密钥加密
看到 sign 或 signature 参数别急着上 hashlib.md5()。真实场景中，它往往是：base64(hmac_sha256(key, method + url_path + query_string + body_json))，其中 key 很可能藏在 JS 里被混淆或动态生成。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 全局搜索 JS 文件中的
sign、crypto、hmac、sha256，重点关注立即执行函数（IIFE）和字符串拼接逻辑 - 留意 key 是否依赖环境：比如用
navigator.userAgent或Math.random()参与生成，这种就得在 PyExecJS 或 Playwright 里还原执行环境 - 用
requests.Session()复用 cookies 和 headers，因为部分签名算法会读取X-Device-ID这类 header 值
绕过检测的关键是「行为链」而非单点参数
只搞定 cursor、timestamp、signature 还不够。服务端会关联检查：请求间隔是否像真人（sleep(1.2) 比 sleep(0.1) 安全）、User-Agent 是否匹配 referer、cookie 中的 sessionid 是否和签名生成时一致。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
selenium或playwright启动真实浏览器跑 JS 提取参数，比纯 requests 模拟更稳——尤其当签名函数调用了WebAssembly或canvas.fingerprint - 若必须用 requests，至少保证：同一 session 复用 cookie、headers 顺序与浏览器一致（用
OrderedDict）、Accept-Encoding设为gzip, deflate - 别忽略 Referer：评论接口常校验上一页详情页 URL，填错会直接 403
逆向最难的不是某一行加密代码，而是你不知道哪一步被监控了。比如某个 __security header 看似无关，其实是用页面 DOM 树深度+脚本加载顺序算出来的，这种只能靠断点调试 JS 才能定位。
