Python爬虫怎么抓评论_逆向分析评论接口翻页参数并构造时间戳与加密Signature

爬虫工程师在抓取评论时，往往会遇到几个扎心的坑：翻页参数不是简单的数字递增，时间戳不对齐服务器就报错，签名算法藏着密钥，最后发现行为链才是决定成败的关键。下面把这几个硬骨头拆开揉碎了聊聊。

评论接口翻页参数不是简单 page=1、page=2

很多网站的评论接口看似用 page 或 offset 控制翻页，实际请求里藏着动态生成的 cursor 或 next 字段，它往往是一串 base64 编码的时间戳+ID 拼接体，比如 MTIzNDU2Nzg5MHx1c2VyX2FhYWFhYQ==。直接递增数字会返回 {"code":400,"msg":"invalid cursor"}。

实操建议：

• 抓包时重点看响应 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"}。

实操建议：

• 先从首页 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 里被混淆或动态生成。

实操建议：

• 全局搜索 JS 文件中的 sign、crypto、hmac、sha256，重点关注立即执行函数（IIFE）和字符串拼接逻辑
• 留意 key 是否依赖环境：比如用 na vigator.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 是否和签名生成时一致。

实操建议：

• 用 selenium 或 playwright 启动真实浏览器跑 JS 提取参数，比纯 requests 模拟更稳——尤其当签名函数调用了 WebAssembly 或 canvas.fingerprint
• 若必须用 requests，至少保证：同一 session 复用 cookie、headers 顺序与浏览器一致（用 OrderedDict）、Accept-Encoding 设为 gzip, deflate
• 别忽略 Referer：评论接口常校验上一页详情页 URL，填错会直接 403

逆向最难的不是某一行加密代码，而是你不知道哪一步被监控了。比如某个 __security header 看似无关，其实是用页面 DOM 树深度+脚本加载顺序算出来的，这种只能靠断点调试 JS 才能定位。