动态页面抓取关键在于绕过前端渲染障碍，优先通过Network面板识别XHR/Fetch接口直取JSON数据，其次才考虑Playwright等工具模拟浏览器行为，并注重会话管理、异常兜底与反爬规避。
动态页面数据抓取的关键不在“能不能”，而在“怎么绕过前端渲染障碍”。核心是模拟真实浏览器行为，让服务器以为你是个真人，而不是脚本。
识别页面是否为动态加载
打开开发者工具（F12），切换到 Network 面板，刷新页面，观察请求类型和响应内容： • 若 HTML 源码中关键数据缺失，但 Elements 面板里有完整内容 → 极大概率是 JS 渲染； • 查看 XHR / Fetch 请求，找带 JSON 响应的接口（如 /api/list、/data?page=1）→ 直接调用更高效； • 注意 URL 是否含 hash（#）或频繁变化的 query 参数（如 _t=171xxxxx）→ 可能是 SPA 路由 + 后端 API 分离。
优先尝试“接口直取”而非“渲染模拟”
多数动态网站本质仍是前后端分离，前端只是调用后端 API。花 10 分钟分析网络请求，往往比写 2 小时 Selenium 脚本更稳更快： • 在 Network → XHR 中筛选出返回结构化数据（JSON）的请求； • 复制 cURL，用 requests + headers 模拟（注意 Cookie、User-Agent、X-Requested-With 等字段）； • 若接口有签名（sign）、时间戳、加密参数，需逆向 JS（查 window.xxx 或混淆后的函数），或用 execjs 执行关键逻辑。
必须用浏览器自动化时，选对工具和策略
不是所有动态页都适合 Selenium；Playwright 和 Pyppeteer 更轻量、更可控： • 启动时加 --no-sandbox --disable-blink-features=AutomationControlled，规避反爬检测； • 等待元素用 page.wait_for_selector('div.item', state='visible')，别用 time.sleep()； • 截图或日志记录关键步骤（如登录后检查用户头像是否加载），便于快速定位失败点； • 分页操作前先确认“下一页”按钮是否可点击（is_enabled），避免因懒加载未触发而空跑。
稳定性的底层保障：会话管理与异常兜底
动态页面交互链长，一个环节失败就全崩。要提前设计容错： • 用 requests.Session() 或 Playwright 的 context（带 storage_state）复用登录态； • 对每个关键动作（点击、输入、跳转）加 try-except，并记录 error_msg 和当前 URL； • 设置最大重试次数（如 retry=3），失败后自动截图 + 保存 HTML 快照，方便回溯； • 抓取频率控制在合理范围（如间隔 1.5–3 秒），配合随机 User-Agent 和 Referer，降低被封概率。
基本上就这些。不复杂，但容易忽略细节——尤其是把“能跑通”当成“能长期跑通”。真正落地时，80% 的问题出在没看清数据从哪来、怎么来的。
