最高效方案是直接请求底层API，需先定位真实数据接口：按F12打开开发者工具，切至Network→XHR/Fetch，刷新页面，筛选含api/json等关键词、响应为application/json的请求，并完整复制headers、cookies及参数。
直接请求底层 API 是最高效、最稳定的方案，前提是能定位到真实数据接口；否则才考虑无头浏览器方案。
怎么快速定位 SPA 的真实数据接口
打开浏览器开发者工具（F12），切到 Network → XHR / Fetch，刷新页面，观察带 JSON 响应的请求。重点看三点：
— Request URL 是否含 api、json、list、v1 等关键词
— Response 内容是否为结构化 JSON（不是 HTML 或空）
— Headers 里是否有 Content-Type: application/json
常见陷阱：有些接口会校验 Referer 或 X-Requested-With，漏掉就返回 403；分页参数如 offset、limit 往往藏在 URL query 中，别手动拼接，用 params= 传字典
requests 模拟 API 请求的关键细节
找到接口后，用 requests.get() 复现比启动浏览器快 10 倍以上，但必须“抄全”浏览器发的请求：
— headers 至少包含 User-Agent 和 Referer，最好从浏览器 Network 面板右键 “Copy → Copy request headers”
— 若响应含 Set-Cookie，后续请求需带上 cookies 参数或复用 requests.Session()
— POST 请求且 Content-Type: application/json 时，用 json= 参数，它会自动序列化并设置 header
— 接口返回 401/403/429 不是缺 header，而是背后有动态 token、时间戳签名或加密参数，硬解成本极高，此时应转向其他方案
什么时候该上无头浏览器：Playwright vs Selenium
当接口加密不可逆、路由切换无规律、或需要模拟滚动/点击等交互行为时，无头浏览器是绕不开的选择：
— Playwright 更推荐：内置智能等待（如 page.wait_for_load_state("networkidle")）、支持多浏览器内核、网络拦截能力更强，且对反爬特征控制更精细
— Selenium 仍可用，但需手动管理 WebDriver 实例生命周期，容易因未 quit 导致进程残留；scrapy-selenium 不是官方包，pip install 会出错，应自行实现中间件 + webdriver-manager
— 注意：两者都默认启用 --headless，但某些网站检测 headless 字符串或缺失 GPU 参数，可加 --disable-blink-features=AutomationControlled 和 --no-sandbox 缓解
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
Browserless 这类远程服务适合什么场景
Browserless 本质是托管版 Chrome API，适合部署在无图形环境的服务器上，省去本地维护浏览器和驱动的麻烦：
— 优点：无需安装 Chrome、可水平扩缩、兼容所有前端框架渲染逻辑
— 缺点：依赖网络稳定性，响应延迟高（通常 1–3 秒），且 token 认证失败时错误信息模糊（如 401 但不说明是 token 过期还是格式错误）
— 使用时注意 gotoOptions.waitUntil 设为 "networkidle0" 而非 "domcontentloaded"，否则可能截到空数据；viewport 尺寸影响部分站点的响应式接口返回字段（比如移动端接口只返回摘要）
真正难的从来不是“能不能拿到”，而是“要不要拿”——接口是否稳定、是否被限流、是否隐含登录态依赖。很多 SPA 的 API 本身没做鉴权，但靠 Referer 或 User-Agent 做轻量拦截，这类最容易绕过；一旦出现加密参数或滑块验证，优先评估业务必要性，而不是一头扎进逆向。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
