现代爬虫技术:Session与Cookie机制详解
你有没有遇到过这种爬虫入门拦路虎:
明明用requests库发了「登录接口POST请求」,用户名密码也全对,再去爬「我的订单/个人中心」,却直接返回 401 Unauthorized 或跳回登录页?
核心原因就藏在「HTTP是无状态协议」里——服务器压根记不住刚才是谁登的。而解决这个问题的「Web标配身份通行证」,就是我们今天要聊的 Cookie + Session。
1. 从无状态到状态管理的演进(极简版)
1.1 早期静态网页的“纯文本困境”
早期的网页全是写死的HTML文件,比如:
- ✅ 优点:服务器压力极小、加载快到飞起、随便丢个Apache/Nginx就能跑
- ❌ 问题:完全没法区分用户——不管是张三、李四、还是黑客,看到的都是一模一样的死内容
1.2 动态网页催生的「身份需求」
后来PHP、ASP、Java Web这些技术出现了,网页可以根据请求实时生成内容,但新问题又来了:
用户登录一次后,浏览购物车、提交订单时,怎么让服务器一直知道这是同一个登录用户?
HTTP协议天生“健忘”,每次请求都是独立的陌生人对话——所以必须给每个对话加个「身份标签」,这就是Cookie和Session的雏形。
2. Cookie:浏览器本地的「小纸条」
2.1 Cookie是什么?
简单说,Cookie是服务器塞给浏览器的、存储在本地的一串小文本数据,最大限制一般在4KB左右。
当浏览器第一次发请求给服务器时:
- 服务器在响应头里加一行
Set-Cookie: 标签名=标签值; 属性1; 属性2... - 浏览器收到后,按照属性要求保存这个小纸条
- 之后每次给同一域名/路径发请求,浏览器都会自动在请求头里带一行
Cookie: 所有符合条件的标签
2.2 关键Cookie属性(爬虫必知,也是安全核心)
2.3 爬虫视角:Cookie长什么样?
用浏览器开发者工具(F12→Network→选个请求→Headers)就能看到:
- 响应头里的Set-Cookie(服务器发的):
- 请求头里的Cookie(浏览器自动带的):
3. Session:服务器上的「用户档案」
3.1 Session是什么?
Cookie虽然能存标签,但不能存敏感信息(比如用户ID、密码哈希——虽然有人存,但完全不安全,容易被窃取)。
所以Session的思路是:
- 服务器生成一个全球唯一的Session ID(比如刚才的
JSESSIONID) - 把Session ID当「档案编号」,把真正的敏感信息(登录状态、用户ID、购物车)存在服务器上(内存、Redis、MySQL都行)
- 把Session ID通过
Set-Cookie塞给浏览器 - 之后浏览器每次发请求,服务器先拿请求头里的Session ID去查档案——查到了就知道是谁,查不到就认为未登录
3.2 常用Session存储方案
4. 爬虫如何处理Session和Cookie?(核心代码)
新手常犯的错误:每次请求都用 requests.get/post() 单独发——这样每次都是「新的浏览器会话」,Cookie不会自动继承,自然登不上。
4.1 基础:用requests.Session()自动管理Cookie
requests库的 Session 对象是模拟浏览器会话的神器,会自动保存、更新、携带Cookie:
4.2 进阶:Cookie持久化(不用每次都登录)
如果要爬的网站Session过期时间很长(比如一周),可以把Cookie存到本地文件,下次直接加载:
5. 爬虫需要注意的安全与合规问题
5.1 反爬相关的小细节
- 别直接用requests库默认的UA:很多网站会把默认UA加入黑名单
- 请求频率别太高:不然会被封IP,可以加
time.sleep()或用代理池 - 尽量模仿真实浏览器的请求顺序:比如先访问首页,再点击登录按钮(先爬登录页拿隐藏的CSRF Token),再发登录请求
5.2 道德与法律合规
- 遵守网站的robots.txt协议:虽然没有强制力,但这是爬虫的基本道德
- 不要爬取敏感个人信息:比如身份证号、手机号、银行卡号
- 不要过度消耗网站的服务器资源:比如同时开1000个线程爬小网站
- 尽量用公开的API:如果网站有官方API,优先用API而不是爬虫
6. 总结
今天我们聊了:
- 为什么需要Session和Cookie:解决HTTP无状态的问题
- Cookie是什么:浏览器本地的小纸条,存标签
- Session是什么:服务器上的用户档案,存敏感信息
- 爬虫如何处理:用
requests.Session()自动管理,用pickle持久化 - 安全与合规:别被封,别违法
作为爬虫开发者,深入理解Session和Cookie的工作原理是入门必备技能,同时也要注意遵守网站规则和法律法规。

