直接用requests+BeautifulSoup爬社交媒体评论基本行不通，因评论由JS动态加载且接口有登录校验、签名加密、频率限流等反爬措施；需用undetected-chromedriver3模拟登录并提取DOM节点，或逆向分析动态API并动态构造参数。
为什么直接用 requests + BeautifulSoup 爬社交媒体评论基本行不通
绝大多数主流社交媒体（如微博、小红书、抖音、Twitter/X）的评论数据都通过前端 JavaScript 动态加载，且接口受严格反爬限制：登录态校验、请求签名、频率限流、IP 封禁。单纯用 requests 请求 HTML 页面，拿到的源码里几乎不含评论内容，BeautifulSoup 解析后得到空列表是常态。
- 真实评论藏在
/api/comment/list或类似 JSON 接口里，需携带cookie、headers（如X-Secrect、Authorization）、有时还需加密参数（如sign、ts） - 部分平台（如小红书）的接口参数含时间戳+随机数+设备指纹哈希，硬逆向成本高、维护难
- 未登录状态下，很多接口直接返回
401或{"code":5001,"msg":"login required"}
用 undetected-chromedriver3 模拟登录并轮询更可靠
对中小规模监控（比如盯 10–20 个账号/话题），用无头浏览器驱动真实渲染页面，再提取 DOM 中已加载的评论节点，比硬啃 API 更稳定。关键不是“快”，而是“能持续跑下去”。
- 必须用
undetected-chromedriver3（非selenium原生 driver），否则极易被webdriver特征检测拦截，触发验证码或封禁 - 登录流程要复用已有 cookie：首次手动登录后保存
cookies.pkl，后续启动时加载，避免每次弹验证码 - 轮询间隔建议 ≥30 秒，评论更新不频繁，太密反而触发风控；可用
time.sleep(30)控制节奏 - 提取评论推荐用
driver.find_elements(By.CSS_SELECTOR, "[data-testid='comment']")这类带语义的 selector，比 XPath 更抗页面结构微调
如何从动态接口中安全提取评论（以微博为例）
微博 PC 端评论走 https://weibo.com/ajax/statuses/buildComments，但参数 id（微博 ID）、count、end_id 都需从页面 JS 变量或响应头中动态获取，不能写死。
- 先用浏览器开发者工具抓一次完整请求，复制
curl命令，用curl2requests工具转成 Python 代码，保留所有 headers 和 cookies -
id通常藏在页面<script>标签里，匹配正则r'"rid"\s*:\s*"([^"]+)"'比硬解析 JSON 更快 - 每次请求后检查响应状态：
if resp.json().get("ok") != 1:就中断，避免无限重试导致 IP 被标记 - 别存原始 HTML，直接提取
["data"][i]["text"]、["user"]["screen_name"]等字段，减少后期清洗成本
实时性与存储怎么平衡
“实时”不等于“毫秒级”，对舆情监控而言，延迟 2–5 分钟可接受，重点是不丢数据、不重复、能回溯。
立即学习“Python免费学习笔记（深入）”；
- 用
sqlite3本地存比直接写文件更稳：建表时设UNIQUE(comment_id)，插入用INSERT OR IGNORE防重复 - 每条评论记录至少存
platform、post_id、comment_id、text、user_id、created_at、ts（采集时间戳） - 不要等攒够 100 条再批量写入，每条独立
INSERT并conn.commit()，断电或崩溃时不丢最近几条 - 如果监控量大（>50 个目标），改用
redis做去重缓存（SET comment_id过期 24h），再落库，避免数据库锁表
真正卡住的从来不是技术选型，而是平台策略变动——某天突然加了新 header 字段，或把评论分页逻辑从 offset 改成 cursor，这些细节不会发公告，只能靠日志里突然出现的空响应去倒推。留好 print(resp.text[:200]) 和请求时间戳，比写漂亮代码重要得多。
