requests + BeautifulSoup 拿不到动态分页内容，因为初始HTML中无后续页数据，其由JavaScript通过AJAX（如fetch/XHR）动态加载；需在Network面板识别JSON接口并模拟请求，或使用Playwright/Selenium渲染。
为什么 requests + BeautifulSoup 拿不到动态分页内容？
因为页面初始 HTML 里根本没加载后续页的数据——它们是通过 JavaScript 发起的 AJAX 请求（比如 fetch 或 XMLHttpRequest）动态插入的。用 requests.get() 只能拿到骨架，BeautifulSoup 解析后自然为空。
关键判断方式：打开浏览器开发者工具（F12），切到 Network → XHR 或 Fetch 标签，翻页时观察是否有新请求发出；如果有，且响应是 JSON，说明走的是接口分页，不是传统 HTML 分页。
- 优先抓接口：比渲染整个页面快得多，也更稳定
- 注意请求头：
User-Agent、Referer、有时还需X-Requested-With或 token 类字段 - 参数常藏在 URL 查询字符串或请求体中，比如
page=2、offset=20、cursor=xxx
如何用 requests 模拟 AJAX 分页请求？
先手动点几页，把请求 URL、Method、Headers、Payload（尤其是分页参数）记下来。然后用 requests 循环调用即可，不需要启动浏览器。
示例场景：某列表接口返回 JSON，分页靠 page 和 limit：
立即学习“Python免费学习笔记（深入）”；
import requests
base_url = "https://api.example.com/items"
headers = {"User-Agent": "Mozilla/5.0", "X-Requested-With": "XMLHttpRequest"}
for page in range(1, 6):
params = {"page": page, "limit": 20}
resp = requests.get(base_url, headers=headers, params=params)
if resp.status_code != 200:
break
data = resp.json()
for item in data.get("list", []):
print(item["title"])
- 别硬写死页数，检查响应里是否有
has_more、total、next_cursor等字段来控制循环 - 加
time.sleep(0.5)避免触发反爬（尤其没有登录态时） - 用
session = requests.Session()复用连接和 cookies，提升效率
什么时候必须用 Selenium 或 Playwright？
当分页逻辑被深度耦合在前端 JS 里：比如按钮点击后触发一连串计算（时间戳签名、加密 offset）、滚动到底部才加载、或翻页请求依赖上一页 DOM 状态时，requests 就无能为力了。
此时要选无头浏览器，但注意：不是所有场景都得用 Selenium —— Playwright 启动更快、API 更稳，对动态等待（如 wait_for_selector）支持更好。
- 避免用
time.sleep()等页面加载，改用page.wait_for_response()监听目标 XHR - 提取数据前，先确认元素已存在：
page.query_selector(".item-list .item") is not None - 关闭图片加载可提速：
page.route("**/*.{png,jpg,gif}", lambda route: route.abort())
绕过反爬时最容易漏掉的三个点
很多脚本跑着跑着就 403 或空响应，问题往往不在分页逻辑本身，而在这些细节：
-
Referer头缺失：某些接口校验来源页，不带会直接拒绝 - Cookie 过期或未同步：登录态、CSRF token、设备指纹相关 cookie 必须复用
- 请求频率突变：第一页正常，第二页被限流——试试加随机延迟、换
User-Agent池
接口分页看似简单，但真实站点常混用多种策略：有的页用 AJAX，有的页靠滚动加载，还有的用 WebSocket 推送。动手前务必在 Network 面板里把每一步请求链路理清楚，而不是只看“翻页”这个动作。
