requests.get()每次新建TCP连接且无状态，无法保持Cookie、Header和Session，导致服务器无法识别用户身份，分页时易返回302跳转或401错误；而Session可自动管理Cookie、复用连接、统一配置请求头，确保登录态持续有效。
直接用 requests.Session() 就能保持 Cookie、Header 和连接复用，不用手动传 token 或重复登录。
为什么不能每次用 requests.get() 单独发请求？
分页接口常依赖服务端 Session（比如 PHPSESSID、JSESSIONID）或登录态 Cookie；单次 requests.get() 每次都是新 TCP 连接 + 无状态请求，服务器认不出你是“同一个人”，第二页大概率返回 302 跳登录页或 401。
- 典型表现：
response.status_code == 302且response.headers.get("Location")指向登录页 - 更隐蔽的情况：返回 200，但数据为空或提示“请先登录”
- Session 复用还能复用底层 TCP 连接，比反复新建连接快 20%~50%
Session 登录后如何安全抓取分页？
登录动作必须由 Session 完成，后续所有分页请求都复用它——这是关键前提。别在登录后把 session.cookies 提出来手动塞给下个 requests.get()。
- 登录请求用
session.post(login_url, data=login_data)，不是requests.post() - 检查登录是否成功：看
session.get(profile_url).status_code是否为 200，或响应里有没有用户昵称字段 - 分页请求统一走
session.get(page_url)，URL 改参数就行，比如f"https://api.example.com/list?page={i}" - 如果接口校验
User-Agent或Referer，在创建 session 后统一设置：session.headers.update({"User-Agent": "xxx", "Referer": "xxx"})
遇到分页返回 403 或空数据怎么办？
大概率是服务端做了额外会话绑定，比如把 Session ID 和 IP、User-Agent 绑定，或要求 Header 中带 X-Requested-With。
- 用浏览器开发者工具抓包，对比「人工点击下一页」和你代码发出的请求，重点看
Cookie、Headers、Query Params三处差异 - 有些站点分页带签名参数（如
sign=xxx），得逆向 JS 生成逻辑，Session本身解决不了这个 - 若发现每次请求后
Set-Cookie都变，说明服务端在滚动 Session，此时要在每次请求后主动保留新 Cookie：session.cookies.set(...)不推荐，应让session自动处理（确保没禁用session.cookies）
Session 不是万能钥匙，它只管住“状态传递”这一环；登录是否成功、分页参数是否合法、防爬策略是否触发，这些得靠你逐层验证。最容易被忽略的是：没确认登录响应里有没有真正写入 Cookie，就急着去请求列表页。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
