先问大家一个问题你在 Python 里写爬虫时是不是遇到过“登录状态莫名其妙失效”“Session 换了个请求就丢 Cookie”“明明带上了 Cookie 却被对方识别成机器人”这类问题如果你点头了那这篇文章就是为你准备的。我把标题里的几件事——Python、Cookie、爬虫、Web 开发——摊开揉碎来聊。Cookie 这个东西说大不大说小不小但它卡在 HTTP 协议的无状态特性和业务系统需要记住“你是谁”之间的矛盾之间是所有 Python 开发者绕不过去的一个核心知识点。无论你是写爬虫采集公开数据还是在 Django/Flask 里做登录鉴权Cookie 的操作水平直接决定你的程序是“能用”还是“稳定可用”。这篇文章不讲虚的从 Cookie 的底层机制讲起到 Python 里几种主流操作方式再到爬虫实战里的完整 Cookie 管理链路最后聊 Web 开发中的安全陷阱一次性把所有关键点串起来。1. 先彻底搞懂 Cookie 是什么别再被面试官问倒Cookie 这个词中文直译是“小饼干”这个比喻其实挺形象的——就像你常去的一家咖啡馆店员记住了你的口味偏好下次你进门不用重新说“拿铁少糖”店员看一眼就知道该怎么做。放在 Web 世界里Cookie 就是服务器发给浏览器的一张“小纸条”浏览器把它收好之后每次访问这个服务器时再把纸条原样带上服务器一看纸条就知道“哦是你啊”。1.1 一个 Cookie 的完整构成以及它到底在请求头里吗先回答热搜词里出现频率最高的一个问题“cookie 是在请求头里吗”答案是是Cookie 是通过 HTTP 请求头中的 Cookie 字段传输的。但 Cookie 本身分为两个方向响应方向服务器通过Set-Cookie响应头告诉浏览器“请保存这条 Cookie”。请求方向浏览器或你的 Python 客户端在后续请求中通过Cookie请求头把存储的 Cookie 原样发回服务器。一条 Cookie 的本质是一个键值对但它身上挂着好几个元数据属性这些属性决定了它的行为和安全性属性作用关键注意事项NameValueCookie 的核心数据Value 一般需要 URL 编码尤其含中文/特殊字符时Domain指定哪个域名携带此 Cookie默认是当前域名跨子域需要显式设置Path指定哪些路径下携带默认是/即整站都带Expires / Max-Age持久化时间不设置则是会话级 Cookie浏览器关闭即失效Secure仅通过 HTTPS 传输生产环境务必开启HttpOnly禁止 JavaScript 读取防 XSS 窃取 Cookie 的关键SameSite控制跨站请求时是否携带与 CSRF 防护直接相关你在 Python 里手动构造 Cookie 时如果只写一个keyvalue字符串服务器端是能解析的但如果你需要精确控制 Domain、Path、过期时间这些属性就必须用到更高级的操作方式。这就引出后面要讲的http.cookiejar。1.2 Cookie 与 Session、Token 的关系三兄弟的分工热搜词里同时出现了“cookie 和 session 和 token 详解”说明很多人对这三者的边界是模糊的。我用一个生活场景把它们拆开Cookie 相当于“通行证”放在客户端每次访问主动出示。Session 相当于“服务器端的档案柜”服务器根据通行证编号Session ID去档案柜里查找对应的用户数据。所以 Session 通常依赖于 Cookie 来传递 Session ID但它自身的状态数据存在服务端。Token 则是“加密通行证”服务器不存档案而是把用户信息、过期时间等签名进一串字符里客户端每次带回来服务器验签即可。三者的核心区别存储位置Cookie 和 Token 在客户端Session 数据在服务端。扩展性Session 在分布式环境下需要共享存储RedisToken 天然无状态适合分布式。安全性Cookie 容易被篡改所以真正敏感的会话标识要配合签名或 HttpOnlyToken 泄漏则等效于账号泄漏因此要设置合理的过期时间。在 Python 爬虫里你最常操作的其实还是 Cookie因为很多老系统只认 Session Cookie 这套组合。在 Web 开发里Django 默认也是 Session Cookie但也能切换成 Token 方案。2. Python 操作 Cookie 的四种武器按场景选择这部分是全文的硬核实操段。Python 里操作 Cookie 的库和姿势非常多但核心其实就几条路标准库http.cookiejar、第三方库requests、底层urllib以及自动化工具selenium。每一种都有它不可替代的使用场景。2.1 标准库 http.cookiejar最底层的 Cookie 容器http.cookiejar是 Python 标准库http模块中的一个子模块它提供了一套完整的 Cookie 存储、解析、过期管理机制。为什么先讲它因为requests内部的 Cookie 管理能力底层就是构建在http.cookiejar之上的。理解了它你就能理解requests.Session为什么能自动维持会话。常用组件有三个CookieJar内存型 Cookie 容器。FileCookieJar文件型容器基类。MozillaCookieJar/LWPCookieJar两种文件格式的落地实现。from http.cookiejar import CookieJar, Cookie from urllib.request import HTTPCookieProcessor, build_opener # 创建内存型 Cookie 容器 cookie_jar CookieJar() # 注册到 opener opener build_opener(HTTPCookieProcessor(cookie_jar)) # 使用 opener 发起请求后cookie_jar 会自动填充 response opener.open(https://httpbin.org/cookies/set?namevalue) # 遍历查看 Cookie for cookie in cookie_jar: print(fName: {cookie.name}, Value: {cookie.value}, Domain: {cookie.domain})这里有一个特别值得注意的点Cookie对象有很多属性包括name、value、domain、path、secure、expires等但expires这个属性比较特殊——它的值是 Unix 时间戳而且CookieJar在构造请求时会自动丢弃已过期的 Cookie。这意味着如果你手动向服务器发送一个已经过期的 Cookie服务器端同样会认为它无效。手动向CookieJar中添加 Cookie 也是可以的之前我踩过一个坑直接用CookieJar.set_cookie()时必须构造一个完整的Cookie对象否则某些属性缺失会导致后续请求不携带。from http.cookiejar import Cookie import time def build_cookie(name, value, domain, path/): return Cookie( version0, namename, valuevalue, portNone, port_specifiedFalse, domaindomain, domain_specifiedTrue, domain_initial_dotFalse, pathpath, path_specifiedTrue, secureFalse, expiresint(time.time()) 3600, # 1小时后过期 discardFalse, commentNone, comment_urlNone, rest{}, rfc2109False, ) jar CookieJar() jar.set_cookie(build_cookie(session_id, abc123, example.com))注意domain_specified这个参数如果设置不对可能导致 Cookie 不生效。CookieJar在判断是否携带某个 Cookie 时会严格比对请求的域名和路径。2.2 requests.Session 的自动 Cookie 管理爬虫的核心利器requests.Session是我日常写爬虫最常用到的对象它的一个核心能力就是透明的自动 Cookie 持久化。所谓透明指的是你不需要手动维护 CookieSession 会在收到Set-Cookie响应头时自动存储并在后续请求中自动携带。import requests session requests.Session() # 第一次请求服务端可能返回 Set-Cookie resp1 session.get(https://httpbin.org/cookies/set?namepython) # 第二次请求session 会自动携带之前的 Cookie resp2 session.get(https://httpbin.org/cookies) print(resp2.json()) # 能看到 namepython这里我要多说一句很多人意识不到requests里的Session对象和直接调用requests.get()的区别。直接调用requests.get()每次都是一次全新的、无状态的请求Cookie 不会被保存也不会被携带而使用Session相当于模拟了一个浏览器的完整会话生命周期。爬虫领域里有一条铁律凡是需要保持登录状态的爬虫一律用Session不要每次裸调requests.get()。但Session的自动 Cookie 管理也有失灵的时候最常见的场景是服务端返回多个Set-Cookie其中某些被标记了HttpOnly。requests并不会因为HttpOnly而拒绝存储它——这个属性是给浏览器用的requests会正常存储和携带。所以如果你遇到“手动设置的 Cookie 能用Session 自动管理的不能用”问题大概率出在 Cookie 的 Domain 或 Path 不匹配上。手动给Session注入 Cookie 有三种姿势姿势一直接构造请求头session.headers.update({Cookie: namepython; tokenabc})适用场景一次性请求不涉及后续自动管理。但注意如果你同时用了session.get()的headers参数和cookies参数两个地方的 Cookie 可能会冲突cookies参数的优先级更高。姿势二通过 cookies 参数传入字典session.get(https://example.com, cookies{name: python})requests会把字典转换成RequestsCookieJar内部再合并到CookieJar中。这种方式的适用场景比较窄——一般用于临时补充个别键值。姿势三直接操作 Session 内部的 CookieJarsession.cookies.set(name, python, domainexample.com, path/)这是我最推荐的方式因为你可以在Session的生命周期里动态调整某个 Cookie而不用每次都要拼接完整请求头。这里有坑session.cookies.set()默认的 domain 和 path 是空字符串这可能导致后续请求不携带它。务必显式指定domain和path。2.3 selenium 里的 Cookie 注入与导出自动化场景的必备技能selenium操作 Cookie 的逻辑和requests完全不同。浏览器是一个独立的进程selenium通过 WebDriver 协议去控制它所以 Cookie 的读写不是基于 Python 对象而是基于浏览器的存储。登录后获取 Cookiefrom selenium import webdriver driver webdriver.Chrome() driver.get(https://example.com/login) # 用户在这里执行登录操作... # 获取所有 Cookie cookies driver.get_cookies() print(cookies) # 输出格式 # [{name: sessionid, value: xxx, domain: example.com, path: /, httpOnly: True, secure: True, expiry: 1234567890}]把 Cookie 给 requests 用import requests session requests.Session() for cookie in driver.get_cookies(): session.cookies.set( cookie[name], cookie[value], domaincookie.get(domain, ), pathcookie.get(path, /), )从 requests 给 selenium 注入 Cookiefor cookie in session.cookies: driver.add_cookie( {name: cookie.name, value: cookie.value, domain: cookie.domain, path: cookie.path} )这里有一个非常关键的时序问题driver.add_cookie()必须在目标域名页面已经加载过之后才能执行。也就是说你得先driver.get(https://example.com)打开一次页面然后再注入 Cookie最后刷新页面才能生效。否则 Selenium 会报InvalidCookieDomainException。这个错误我在新手阶段踩过无数回写在这里帮你们避坑。另一个经验之谈get_cookies()拿到的expiry字段是 Unix 时间戳但add_cookie()需要的也是秒级时间戳这俩是对得上的。但如果你是手动构造 Cookie 字典expiry不写也没关系浏览器会把它当成会话级 Cookie 处理。2.4 urllib 的硬核操作不用 requests 时你还有后路虽然现在 99% 的场景我都用requests但偶尔会遇到一些环境限制比如内网环境无法安装第三方库或者公司安全规范强制只能用标准库。这时候urllib.requesthttp.cookiejar就是唯一的出路。from urllib.request import HTTPCookieProcessor, Request, build_opener from http.cookiejar import CookieJar jar CookieJar() opener build_opener(HTTPCookieProcessor(jar)) # 首次请求会自动保存 Set-Cookie resp opener.open(https://httpbin.org/cookies/set?namepython) # 第二次请求自动携带 Cookie resp opener.open(https://httpbin.org/cookies) print(resp.read().decode())urllib的build_opener其实和requests.Session里的 Cookie 管理逻辑很相似都是基于HTTPCookieProcessor注册一个处理器只是 API 风格更底层。如果你想在urllib中手动指定 Cookie可以用Request的add_header()req Request(https://example.com, headers{Cookie: namepython}) resp opener.open(req)注意如果你既通过HTTPCookieProcessor注册了 Cookie 管理又手动添加了Cookie请求头后者会被opener自动生成的 Cookie 头覆盖掉。这个细节很容易让初次接触的人产生困惑明明设置了Cookie头服务端却看不到。原因就出在urllib的处理器会在请求发出前统一处理 Cookie 头手动设置的Cookie头会被丢弃。3. 爬虫实战一套完整的 Cookie 管理链路爬虫里对 Cookie 的操作绝不是“把登录后的 Cookie 复制粘贴到代码里”那么简单。一个稳定的爬虫系统至少要解决 Cookie 从“获取”到“存储”再到“使用”和“更新”的完整闭环问题。3.1 登录后拿到 Cookie模拟登录的完整流程模拟登录是爬虫获取 Cookie 最常用的方式。它的本质是模拟浏览器向登录接口发送账号密码接收服务端返回的Set-Cookie并保存到本地。以某个典型的表单登录为例import requests from http.cookiejar import MozillaCookieJar session requests.Session() # 1. 先访问登录页获取必要的隐藏字段如 CSRF Token login_page session.get(https://example.com/login) # 解析页面中 hidden input 的 token 值 ... # 2. 构造登录 POST 请求 login_data { username: your_account, password: your_password, csrf_token: csrf_token_value, } resp session.post( https://example.com/login, datalogin_data, headers{Referer: https://example.com/login}, allow_redirectsFalse, # 关闭自动重定向便于检查中间响应 ) # 3. 检查登录是否成功 if resp.status_code 302 and Location in resp.headers: print(登录成功准备跳转到首页) # 4. 持久化 Cookie 到文件 cookie_jar MozillaCookieJar(cookies.txt) for cookie in session.cookies: cookie_jar.set_cookie(cookie) cookie_jar.save(ignore_discardTrue, ignore_expiresTrue)这里有几个值得展开的细节为什么allow_redirectsFalse很多登录流程是POST 登录 → 302 重定向 → 首页。如果开启了自动重定向requests会直接跟随到首页中间登录接口的Set-Cookie依然会保存这个不影响。但有些系统的登录逻辑里登录成功和失败都返回 302区别在于Location指向哪里。关闭自动重定向能让你精确控制响应结构避免在调试时被重定向绕晕。为什么用MozillaCookieJarMozillaCookieJar保存的文件格式是 Netscape 格式这种格式被很多 HTTP 工具如 curl、wget兼容。如果你后续想把这套 Cookie 导出给其他工具用这个格式最通用。ignore_discardTrue和ignore_expiresTrue不要漏。前者表示即使 Cookie 是会话级的没有设置 Expires也保存到文件后者表示即使 Cookie 已过期也允许写入文件。漏掉任何一个你保存下来的文件都可能是空的。3.2 持久化方案对比文件、数据库、还是 RedisCookie 持久化方案的选择取决于爬虫系统的规模。我按使用场景从轻到重列一下方案适用场景优点缺点本地文件MozillaCookieJar单机爬虫、调试阶段简单直接人类可读不便于多任务共享Redis Hash分布式爬虫读写快、支持过期时间、多进程共享需要维护 Redis 服务MySQL/MongoDB账号管理系统可追溯历史、可加密存储读写效率低于 Redis单机调试用文件生产环境用 Redis。这是我踩过坑后总结出来的经验。文件方案在多进程爬虫下会遇到竞争写入问题两个进程同时写同一个 Cookie 文件可能互相覆盖。而 Redis 天然是单线程写入加上EXPIRE命令还能自动管理过期时间简直是为 Cookie 存储量身定制的。Redis 存储的典型结构import redis import json r redis.Redis(hostlocalhost, port6379, db0) # 存储某个账号的 Cookie account user_001 cookie_dict { sessionid: abc123, csrftoken: xyz789, } r.hset(fcookies:{account}, mappingcookie_dict) r.expire(fcookies:{account}, 3600 * 8) # 8小时过期 # 读取 cookies r.hgetall(fcookies:{account}) cookie_str ; .join(f{k.decode()}{v.decode()} for k, v in cookies.items())这里有个细节Redis 的hset和expire之间并不是原子操作如果你在并发场景下读取可能读到还没设置过期时间的“中间态”。实际项目中可以用 Lua 脚本或者管道保证原子性。3.3 Cookie 失效与自动刷新机制爬虫稳定性的分水岭Cookie 是会失效的原因包括过期时间到了、服务端主动注销、账号被风控、IP 变化触发安全策略等。一个只登录一次就无限期使用的爬虫是不存在的所以在设计时需要把“Cookie 刷新”纳入整体架构。我在生产环境里用得最多的是一种简单但有效的“双层校验 自动重登”策略定义一个校验函数传入Session判断当前 Cookie 是否有效。判断方法不一定是访问登录态接口有时候直接访问一个需要登录才能看的页面看返回里有没有“请登录”的关键词即可。def is_login_valid(session, check_urlhttps://example.com/dashboard): resp session.get(check_url, timeout10) if resp.status_code 200 and 请登录 not in resp.text: return True return False在业务请求循环中每执行 N 次请求后调用一次校验函数。如果发现失效立即触发重新登录流程更新 Cookie 池。from datetime import datetime last_check_time datetime.now() def ensure_valid_session(session, account, check_interval300): global last_check_time now datetime.now() if (now - last_check_time).seconds check_interval: if not is_login_valid(session): session login_and_get_session(account) refresh_cookie_pool(session, account) last_check_time now return session重登时注意限速。频繁登录触发风控的概率极高建议在重登逻辑里加一个随机休眠比如time.sleep(random.uniform(3, 8))模拟人工登录节奏。这里再提醒一个容易忽略的细节Cookie 池里同一个账号不要同时供多个任务使用。如果两个爬虫进程同时携带同一份 Cookie 去请求同一个网站服务端很可能会因为请求频率异常触发账号封禁。要么给账号加锁要么按账号做任务分片。3.4 分布式爬虫场景下Cookie 池该怎么设计热搜词里有一个“分布式爬虫”和“藏宝阁 爬虫”同时出现说明不少人已经在实战分布式采集了。分布式爬虫的 Cookie 管理比单机复杂很多核心问题在于多个 worker 节点需要共享同一套账号 Cookie同时要避免并发冲突。我的推荐方案是基于 Redis 账号锁的结构账号列表存储Redis Set 中保存所有可用账号。Cookie 存储每个账号的 Cookie 存一个 Hash字段名是域名。租借机制worker 从 Redis 中SPOP取出一个账号使用期间加锁结束后归还。租约过期使用SET NX EX命令实现带超时的锁防止 worker 崩溃导致账号死锁。import redis import time import uuid r redis.Redis(hostlocalhost, port6379, db0) def acquire_account(account, lease_time300): lock_key faccount_lock:{account} token str(uuid.uuid4()) # SET NX EX 原子操作 ok r.set(lock_key, token, nxTrue, exlease_time) if ok: return token return None def release_account(account, token): lock_key faccount_lock:{account} # 使用 Lua 保证“先验证再删除”的原子性 script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end r.eval(script, 1, lock_key, token)这部分的实现难点不在代码而在并发思维。你永远要假设最坏情况某个 worker 节点可能拿到账号后突然崩溃锁必须有过期时间某个 Cookie 可能在请求过程中被服务端主动作废账号必须能被快速踢回池子并触发重新登录。4. Web 开发实战Cookie 的正确打开方式与安全防护前面聊的都是“怎么用 Python 去拿/带 Cookie”这一部分要反转视角——如果你是服务端开发者怎么正确地设置、校验和保护 Cookie。这对于写爬虫的人同等重要因为只有了解了服务端怎么设计你才能知道爬虫端怎么应对。4.1 Django 中 Cookie 的读写与签名机制Django 提供了非常完备的 Cookie 操作 API。设置 Cookie 用HttpResponse.set_cookie()读取用request.COOKIES.get()删除用HttpResponse.delete_cookie()。from django.http import HttpResponse def set_cookie_view(request): resp HttpResponse(Cookie 已设置) resp.set_cookie( username, python_crawler, max_age60 * 60 * 24, # 1天有效期 domain.example.com, # 跨子域共享 path/, secureTrue, # 仅 HTTPS httponlyTrue, # 禁止 JS 读取防 XSS samesiteLax, # 跨站请求限制 ) return respmax_age和expires的区别是新手容易搞混的地方。max_age是相对时间秒浏览器会把它换算成绝对过期时间expires是绝对时间datetime 对象。两者同时设置时现代浏览器以max_age为准但为了兼容老版本 Safari建议两个都设置。Django 的set_signed_cookie()是一个值得单独拎出来说的功能——它给 Cookie 的值加了一层签名防止客户端篡改。原理是服务端用SECRET_KEY对 Cookie 值生成一个 HMAC 签名附在后面客户端改动任何一个字符服务端在读取时验签就会失败。def set_signed_cookie_view(request): resp HttpResponse(已设置签名 Cookie) resp.set_signed_cookie(user_id, 12345, saltmy-salt, max_age60 * 60) return resp def read_signed_cookie_view(request): try: user_id request.get_signed_cookie(user_id, saltmy-salt) return HttpResponse(f用户 ID: {user_id}) except Exception as e: return HttpResponse(fCookie 校验失败: {e}, status400)这里有个细节值得留意salt参数的作用是防止同一个SECRET_KEY在不同场景下生成的签名被复用。比如你给user_id和username都用同一个 salt攻击者就可能把user_id的签名套到username上。所以每个业务字段的salt都要单独设计。4.2 Flask 中 Cookie 的操作方式make_response 是关键Flask 的 Cookie 操作与 Django 有一个显著不同你无法直接在视图函数中操作一个“隐式”的响应对象必须通过make_response()显式创建响应对象然后调用它的set_cookie()方法。from flask import Flask, make_response, request app Flask(__name__) app.route(/set) def set_cookie(): resp make_response(Cookie 已设置) resp.set_cookie( session_id, abc123, max_age60 * 60 * 24, httponlyTrue, secureTrue, samesiteLax, ) return resp app.route(/get) def get_cookie(): session_id request.cookies.get(session_id) return f得到 Session ID: {session_id} app.route(/delete) def delete_cookie(): resp make_response(Cookie 已删除) resp.delete_cookie(session_id) return respdelete_cookie()并不是真的从浏览器中删除 Cookie而是通过设置一个立即过期的同名 Cookie 来让浏览器“放弃”它。所以delete_cookie()的参数里必须包含与设置时相同的path和domain否则删除会无效。这个坑我曾经在线上环境踩过设置的path/删除时没传结果 Cookie 一直删不掉用户永远处于登录状态。Flask 中如果要实现类似 Django 的签名 Cookie可以用itsdangerous库。Flask 的session机制内部就使用了它所以直接引入成本很低from itsdangerous import URLSafeTimedSerializer serializer URLSafeTimedSerializer(secret-key, saltcookie-signature) # 签名 signed_value serializer.dumps({user_id: 12345}) # 验签max_age 控制最长有效期 try: data serializer.loads(signed_value, max_age60 * 60) except Exception as e: print(验签失败, e)4.3 企业级 Cookie 安全清单JWT、HttpOnly、SameSite 一个都不能少热搜词里有“企业级 web 开发”和“java controller 层如何防护 防止爬虫”可见不少人在做 Web 安全时都会把 Cookie 防护作为重点。这里我把服务端设置 Cookie 时的安全配置整理成一张对照表方便你直接抄作业安全项配置值防护目标HttpOnlyTrue防止 XSS 攻击通过document.cookie窃取会话SecureTrue防止 HTTP 明文传输中被截获SameSiteLax或Strict防止 CSRF 攻击Domain尽量不跨子域缩小 Cookie 影响范围Path尽量具体避免关键 Cookie 被无关路径携带过期时间越短越好减少被盗用后被长期使用的风险值的内容只存标识符不存明文敏感信息即使泄露损失可控关于 TokenJWT与 Cookie 的选择我的建议是新一代系统优先考虑 Token HttpOnly Cookie 的混合方案。将 JWT 放在 HttpOnly Cookie 中既利用了 Cookie 的自动携带特性又避免了将 Token 暴露给 JavaScript还能防止一部分 CSRF 攻击配合 SameSite。这套方案在前后端分离的项目里已经非常成熟。关于“防止爬虫”的思考热搜词里“java controller 层如何防护 防止爬虫”这个问题本质上和 Cookie 也有强关联。服务端可以通过检测 Cookie 的生成方式来判断是真人还是爬虫——比如真人浏览时会产生一系列合理的 Cookie 更新轨迹而爬虫往往是固定 Cookie。但反过来作为一个写爬虫的人你要意识到防爬没有一个银弹Cookie 只是其中的一环。真正稳健的爬虫策略不是“攻克”某个防护点而是模拟真实用户的完整行为链路——包括 Cookie 的生成时机、更新时机、过期时机。这算是跨视角的一个补充心得。5. 实战中的高频问题与排查技巧实录每个写爬虫或做 Web 开发的人都会在 Cookie 上栽过跟头。我把这些年遇到的典型问题整理成速查表附带排查思路和最终解决方案。5.1 Cookie 不生效为什么设置了你却没等到现象服务端明明返回了Set-Cookie但后续请求没有携带或者手动构造的 Cookie 发送了服务端却认为未登录。排查思路一步步来先打印原始响应头确认Set-Cookie真的存在resp session.post(https://example.com/login, datalogin_data) print(resp.headers.get(Set-Cookie))检查 Domain 和 Path。Cookie 只有在请求的域名和路径匹配时才会上送。比如你登录的是www.example.com拿到的 Cookie Domain 是.example.com这个对api.example.com是有效的但如果 Domain 是www.example.com那它就不会被携带到api.example.com上。检查 Secure 标志。如果Set-Cookie中带了Secure属性那它只在 HTTPS 请求中上送。如果你用 HTTP 访问测试环境这个 Cookie 永远不会被带过去。检查 requests 是否忽略了 Cookie。有一种情况你直接通过headers{Cookie: ...}设置了 Cookie但底层的CookieJar里没有对应记录在后续的自动重定向或跨域跳转中这个手动 Header 可能被丢弃。这种情况建议改用session.cookies.set()的方式。5.2 浏览器开发者工具看不到 Cookie并非代码问题热搜词里有“chome 开发者工具没有 cookie”这个问题我见过很多次。排查方向有两个第一你查看的位置不对。开发者工具里看 Cookie 有两个入口Network面板中某个具体请求的Headers标签页里有Request Headers的Cookie字段Application面板里有Storage → Cookies → 你的域名。如果你在Network面板的Payload或Preview里找自然找不到。第二当前浏览器配置了“阻止所有 Cookie”。在 Chrome 的设置 → 隐私和安全 → Cookie 及其他网站数据里如果选择了“阻止所有第三方 Cookie”某些场景下连第一方 Cookie 也会受影响。把站点加入白名单即可。还有一个容易被忽略的细节Chrome 的「隐身模式」默认允许 Cookie但不允许持久化 Cookie因为关闭窗口即清空。所以如果你测试时勾选了隐身模式切回常规模式后 Cookie 文件可能已经清理了。5.3 Chrome 无法导出 Cookie换条路走通“360 浏览器怎么导出 cookie”和“chrome 开发者工具没有 cookie”这两个热搜词背后其实是同一个需求某些工具需要浏览器登录态的 Cookie。最直接的办法是用浏览器扩展如 EditThisCookie但如果你不想装扩展另一个稳定方案是用selenium自动登录后获取 Cookie。from selenium import webdriver from selenium.webdriver.common.by import By import time driver webdriver.Chrome() driver.get(https://example.com/login) driver.find_element(By.NAME, username).send_keys(your_account) driver.find_element(By.NAME, password).send_keys(your_password) driver.find_element(By.TAG_NAME, button).click() time.sleep(3) # 等页面跳转 cookies driver.get_cookies() for cookie in cookies: print(f{cookie[name]}{cookie[value]})这里有个额外的坑如果登录过程有滑块验证码或人脸验证selenium方案也搞不定必须人工介入。这叫做“半自动登录”在爬虫领域很常见开着浏览器让真人完成验证码部分代码自动接管后续请求。5.4 requests 丢失 Cookie 的幕后黑手重定向与跨域requests.Session在自动重定向时通常能保留 Cookie但有一种场景会丢从http://a.com重定向到http://b.com然后b.com又设置了 Domain 为b.com的新 Cookie。此时a.com的 Cookie 对新域没有意义requests不会把它带过去。这不是 Bug而是行为正确。解决思路如果业务场景需要跨域共享登录态要么在主域根下设置 Domain要么改为服务端 Token 方案把 Token 作为查询参数或自定义 Header 在跨域跳转中传递。我之前排查过一个诡异问题requests在某些环境里会丢掉Path为/的 Cookie。后来发现是代码里用了requests.get()而非session.get()导致 Cookie 没有经过同一个Session的 Jar 管理。这个问题非常值得自查——你在代码的哪里发起了请求Cookie 就在哪里管理不要混用裸请求和 Session 请求。6. 从爬虫到 Web 开发Cookie 操作的心法总结写到这里我把这些年的核心体会浓缩一下。Cookie 操作在所有语言里都遵循同一套底层逻辑读请求头、写响应头、存储和过期。Python 只是恰好提供了多种工具让你能在不同场景下优雅地操作它。http.cookiejar是基础requests.Session是主力selenium是补漏Django/Flask 的 Cookie API 是开发侧的落点。我最后再分享一个小技巧。写爬虫的人一定要学会用手机端的 Cookie 来反查 Web 端的问题。比如热搜词里“网易云 cookie 手机怎么获取”这种问题本质上就是想在非浏览器环境下获取 Token。遇到这种情况我的习惯是先用抓包工具如 Charles 或 Fiddler抓取移动端 HTTP 请求直接看请求头里的Cookie字段或Authorization字段。因为移动端 App 的请求头往往比浏览器的更简洁、更直接能帮你快速定位到真正在用的凭证格式然后再回 Python 代码里构造对应的请求。Cookie 这东西单独看是个小知识点但它串联着 HTTP 协议、会话管理、安全防护、爬虫工程化、Web 框架设计这么多环节值得花时间彻底搞懂。希望这篇文章能帮你把这条链路打通后续遇到任何与 Cookie 相关的报错都能冷静地一步步排查。 
长河君 · 2026/10/10 19:27:32 · 阅读 1.2k Python 爬虫与 Web 开发中的 Cookie 操作全攻略
先问大家一个问题你在 Python 里写爬虫时是不是遇到过“登录状态莫名其妙失效”“Session 换了个请求就丢 Cookie”“明明带上了 Cookie 却被对方识别成机器人”这类问题如果你点头了那这篇文章就是为你准备的。我把标题里的几件事——Python、Cookie、爬虫、Web 开发——摊开揉碎来聊。Cookie 这个东西说大不大说小不小但它卡在 HTTP 协议的无状态特性和业务系统需要记住“你是谁”之间的矛盾之间是所有 Python 开发者绕不过去的一个核心知识点。无论你是写爬虫采集公开数据还是在 Django/Flask 里做登录鉴权Cookie 的操作水平直接决定你的程序是“能用”还是“稳定可用”。这篇文章不讲虚的从 Cookie 的底层机制讲起到 Python 里几种主流操作方式再到爬虫实战里的完整 Cookie 管理链路最后聊 Web 开发中的安全陷阱一次性把所有关键点串起来。1. 先彻底搞懂 Cookie 是什么别再被面试官问倒Cookie 这个词中文直译是“小饼干”这个比喻其实挺形象的——就像你常去的一家咖啡馆店员记住了你的口味偏好下次你进门不用重新说“拿铁少糖”店员看一眼就知道该怎么做。放在 Web 世界里Cookie 就是服务器发给浏览器的一张“小纸条”浏览器把它收好之后每次访问这个服务器时再把纸条原样带上服务器一看纸条就知道“哦是你啊”。1.1 一个 Cookie 的完整构成以及它到底在请求头里吗先回答热搜词里出现频率最高的一个问题“cookie 是在请求头里吗”答案是是Cookie 是通过 HTTP 请求头中的 Cookie 字段传输的。但 Cookie 本身分为两个方向响应方向服务器通过Set-Cookie响应头告诉浏览器“请保存这条 Cookie”。请求方向浏览器或你的 Python 客户端在后续请求中通过Cookie请求头把存储的 Cookie 原样发回服务器。一条 Cookie 的本质是一个键值对但它身上挂着好几个元数据属性这些属性决定了它的行为和安全性属性作用关键注意事项NameValueCookie 的核心数据Value 一般需要 URL 编码尤其含中文/特殊字符时Domain指定哪个域名携带此 Cookie默认是当前域名跨子域需要显式设置Path指定哪些路径下携带默认是/即整站都带Expires / Max-Age持久化时间不设置则是会话级 Cookie浏览器关闭即失效Secure仅通过 HTTPS 传输生产环境务必开启HttpOnly禁止 JavaScript 读取防 XSS 窃取 Cookie 的关键SameSite控制跨站请求时是否携带与 CSRF 防护直接相关你在 Python 里手动构造 Cookie 时如果只写一个keyvalue字符串服务器端是能解析的但如果你需要精确控制 Domain、Path、过期时间这些属性就必须用到更高级的操作方式。这就引出后面要讲的http.cookiejar。1.2 Cookie 与 Session、Token 的关系三兄弟的分工热搜词里同时出现了“cookie 和 session 和 token 详解”说明很多人对这三者的边界是模糊的。我用一个生活场景把它们拆开Cookie 相当于“通行证”放在客户端每次访问主动出示。Session 相当于“服务器端的档案柜”服务器根据通行证编号Session ID去档案柜里查找对应的用户数据。所以 Session 通常依赖于 Cookie 来传递 Session ID但它自身的状态数据存在服务端。Token 则是“加密通行证”服务器不存档案而是把用户信息、过期时间等签名进一串字符里客户端每次带回来服务器验签即可。三者的核心区别存储位置Cookie 和 Token 在客户端Session 数据在服务端。扩展性Session 在分布式环境下需要共享存储RedisToken 天然无状态适合分布式。安全性Cookie 容易被篡改所以真正敏感的会话标识要配合签名或 HttpOnlyToken 泄漏则等效于账号泄漏因此要设置合理的过期时间。在 Python 爬虫里你最常操作的其实还是 Cookie因为很多老系统只认 Session Cookie 这套组合。在 Web 开发里Django 默认也是 Session Cookie但也能切换成 Token 方案。2. Python 操作 Cookie 的四种武器按场景选择这部分是全文的硬核实操段。Python 里操作 Cookie 的库和姿势非常多但核心其实就几条路标准库http.cookiejar、第三方库requests、底层urllib以及自动化工具selenium。每一种都有它不可替代的使用场景。2.1 标准库 http.cookiejar最底层的 Cookie 容器http.cookiejar是 Python 标准库http模块中的一个子模块它提供了一套完整的 Cookie 存储、解析、过期管理机制。为什么先讲它因为requests内部的 Cookie 管理能力底层就是构建在http.cookiejar之上的。理解了它你就能理解requests.Session为什么能自动维持会话。常用组件有三个CookieJar内存型 Cookie 容器。FileCookieJar文件型容器基类。MozillaCookieJar/LWPCookieJar两种文件格式的落地实现。from http.cookiejar import CookieJar, Cookie from urllib.request import HTTPCookieProcessor, build_opener # 创建内存型 Cookie 容器 cookie_jar CookieJar() # 注册到 opener opener build_opener(HTTPCookieProcessor(cookie_jar)) # 使用 opener 发起请求后cookie_jar 会自动填充 response opener.open(https://httpbin.org/cookies/set?namevalue) # 遍历查看 Cookie for cookie in cookie_jar: print(fName: {cookie.name}, Value: {cookie.value}, Domain: {cookie.domain})这里有一个特别值得注意的点Cookie对象有很多属性包括name、value、domain、path、secure、expires等但expires这个属性比较特殊——它的值是 Unix 时间戳而且CookieJar在构造请求时会自动丢弃已过期的 Cookie。这意味着如果你手动向服务器发送一个已经过期的 Cookie服务器端同样会认为它无效。手动向CookieJar中添加 Cookie 也是可以的之前我踩过一个坑直接用CookieJar.set_cookie()时必须构造一个完整的Cookie对象否则某些属性缺失会导致后续请求不携带。from http.cookiejar import Cookie import time def build_cookie(name, value, domain, path/): return Cookie( version0, namename, valuevalue, portNone, port_specifiedFalse, domaindomain, domain_specifiedTrue, domain_initial_dotFalse, pathpath, path_specifiedTrue, secureFalse, expiresint(time.time()) 3600, # 1小时后过期 discardFalse, commentNone, comment_urlNone, rest{}, rfc2109False, ) jar CookieJar() jar.set_cookie(build_cookie(session_id, abc123, example.com))注意domain_specified这个参数如果设置不对可能导致 Cookie 不生效。CookieJar在判断是否携带某个 Cookie 时会严格比对请求的域名和路径。2.2 requests.Session 的自动 Cookie 管理爬虫的核心利器requests.Session是我日常写爬虫最常用到的对象它的一个核心能力就是透明的自动 Cookie 持久化。所谓透明指的是你不需要手动维护 CookieSession 会在收到Set-Cookie响应头时自动存储并在后续请求中自动携带。import requests session requests.Session() # 第一次请求服务端可能返回 Set-Cookie resp1 session.get(https://httpbin.org/cookies/set?namepython) # 第二次请求session 会自动携带之前的 Cookie resp2 session.get(https://httpbin.org/cookies) print(resp2.json()) # 能看到 namepython这里我要多说一句很多人意识不到requests里的Session对象和直接调用requests.get()的区别。直接调用requests.get()每次都是一次全新的、无状态的请求Cookie 不会被保存也不会被携带而使用Session相当于模拟了一个浏览器的完整会话生命周期。爬虫领域里有一条铁律凡是需要保持登录状态的爬虫一律用Session不要每次裸调requests.get()。但Session的自动 Cookie 管理也有失灵的时候最常见的场景是服务端返回多个Set-Cookie其中某些被标记了HttpOnly。requests并不会因为HttpOnly而拒绝存储它——这个属性是给浏览器用的requests会正常存储和携带。所以如果你遇到“手动设置的 Cookie 能用Session 自动管理的不能用”问题大概率出在 Cookie 的 Domain 或 Path 不匹配上。手动给Session注入 Cookie 有三种姿势姿势一直接构造请求头session.headers.update({Cookie: namepython; tokenabc})适用场景一次性请求不涉及后续自动管理。但注意如果你同时用了session.get()的headers参数和cookies参数两个地方的 Cookie 可能会冲突cookies参数的优先级更高。姿势二通过 cookies 参数传入字典session.get(https://example.com, cookies{name: python})requests会把字典转换成RequestsCookieJar内部再合并到CookieJar中。这种方式的适用场景比较窄——一般用于临时补充个别键值。姿势三直接操作 Session 内部的 CookieJarsession.cookies.set(name, python, domainexample.com, path/)这是我最推荐的方式因为你可以在Session的生命周期里动态调整某个 Cookie而不用每次都要拼接完整请求头。这里有坑session.cookies.set()默认的 domain 和 path 是空字符串这可能导致后续请求不携带它。务必显式指定domain和path。2.3 selenium 里的 Cookie 注入与导出自动化场景的必备技能selenium操作 Cookie 的逻辑和requests完全不同。浏览器是一个独立的进程selenium通过 WebDriver 协议去控制它所以 Cookie 的读写不是基于 Python 对象而是基于浏览器的存储。登录后获取 Cookiefrom selenium import webdriver driver webdriver.Chrome() driver.get(https://example.com/login) # 用户在这里执行登录操作... # 获取所有 Cookie cookies driver.get_cookies() print(cookies) # 输出格式 # [{name: sessionid, value: xxx, domain: example.com, path: /, httpOnly: True, secure: True, expiry: 1234567890}]把 Cookie 给 requests 用import requests session requests.Session() for cookie in driver.get_cookies(): session.cookies.set( cookie[name], cookie[value], domaincookie.get(domain, ), pathcookie.get(path, /), )从 requests 给 selenium 注入 Cookiefor cookie in session.cookies: driver.add_cookie( {name: cookie.name, value: cookie.value, domain: cookie.domain, path: cookie.path} )这里有一个非常关键的时序问题driver.add_cookie()必须在目标域名页面已经加载过之后才能执行。也就是说你得先driver.get(https://example.com)打开一次页面然后再注入 Cookie最后刷新页面才能生效。否则 Selenium 会报InvalidCookieDomainException。这个错误我在新手阶段踩过无数回写在这里帮你们避坑。另一个经验之谈get_cookies()拿到的expiry字段是 Unix 时间戳但add_cookie()需要的也是秒级时间戳这俩是对得上的。但如果你是手动构造 Cookie 字典expiry不写也没关系浏览器会把它当成会话级 Cookie 处理。2.4 urllib 的硬核操作不用 requests 时你还有后路虽然现在 99% 的场景我都用requests但偶尔会遇到一些环境限制比如内网环境无法安装第三方库或者公司安全规范强制只能用标准库。这时候urllib.requesthttp.cookiejar就是唯一的出路。from urllib.request import HTTPCookieProcessor, Request, build_opener from http.cookiejar import CookieJar jar CookieJar() opener build_opener(HTTPCookieProcessor(jar)) # 首次请求会自动保存 Set-Cookie resp opener.open(https://httpbin.org/cookies/set?namepython) # 第二次请求自动携带 Cookie resp opener.open(https://httpbin.org/cookies) print(resp.read().decode())urllib的build_opener其实和requests.Session里的 Cookie 管理逻辑很相似都是基于HTTPCookieProcessor注册一个处理器只是 API 风格更底层。如果你想在urllib中手动指定 Cookie可以用Request的add_header()req Request(https://example.com, headers{Cookie: namepython}) resp opener.open(req)注意如果你既通过HTTPCookieProcessor注册了 Cookie 管理又手动添加了Cookie请求头后者会被opener自动生成的 Cookie 头覆盖掉。这个细节很容易让初次接触的人产生困惑明明设置了Cookie头服务端却看不到。原因就出在urllib的处理器会在请求发出前统一处理 Cookie 头手动设置的Cookie头会被丢弃。3. 爬虫实战一套完整的 Cookie 管理链路爬虫里对 Cookie 的操作绝不是“把登录后的 Cookie 复制粘贴到代码里”那么简单。一个稳定的爬虫系统至少要解决 Cookie 从“获取”到“存储”再到“使用”和“更新”的完整闭环问题。3.1 登录后拿到 Cookie模拟登录的完整流程模拟登录是爬虫获取 Cookie 最常用的方式。它的本质是模拟浏览器向登录接口发送账号密码接收服务端返回的Set-Cookie并保存到本地。以某个典型的表单登录为例import requests from http.cookiejar import MozillaCookieJar session requests.Session() # 1. 先访问登录页获取必要的隐藏字段如 CSRF Token login_page session.get(https://example.com/login) # 解析页面中 hidden input 的 token 值 ... # 2. 构造登录 POST 请求 login_data { username: your_account, password: your_password, csrf_token: csrf_token_value, } resp session.post( https://example.com/login, datalogin_data, headers{Referer: https://example.com/login}, allow_redirectsFalse, # 关闭自动重定向便于检查中间响应 ) # 3. 检查登录是否成功 if resp.status_code 302 and Location in resp.headers: print(登录成功准备跳转到首页) # 4. 持久化 Cookie 到文件 cookie_jar MozillaCookieJar(cookies.txt) for cookie in session.cookies: cookie_jar.set_cookie(cookie) cookie_jar.save(ignore_discardTrue, ignore_expiresTrue)这里有几个值得展开的细节为什么allow_redirectsFalse很多登录流程是POST 登录 → 302 重定向 → 首页。如果开启了自动重定向requests会直接跟随到首页中间登录接口的Set-Cookie依然会保存这个不影响。但有些系统的登录逻辑里登录成功和失败都返回 302区别在于Location指向哪里。关闭自动重定向能让你精确控制响应结构避免在调试时被重定向绕晕。为什么用MozillaCookieJarMozillaCookieJar保存的文件格式是 Netscape 格式这种格式被很多 HTTP 工具如 curl、wget兼容。如果你后续想把这套 Cookie 导出给其他工具用这个格式最通用。ignore_discardTrue和ignore_expiresTrue不要漏。前者表示即使 Cookie 是会话级的没有设置 Expires也保存到文件后者表示即使 Cookie 已过期也允许写入文件。漏掉任何一个你保存下来的文件都可能是空的。3.2 持久化方案对比文件、数据库、还是 RedisCookie 持久化方案的选择取决于爬虫系统的规模。我按使用场景从轻到重列一下方案适用场景优点缺点本地文件MozillaCookieJar单机爬虫、调试阶段简单直接人类可读不便于多任务共享Redis Hash分布式爬虫读写快、支持过期时间、多进程共享需要维护 Redis 服务MySQL/MongoDB账号管理系统可追溯历史、可加密存储读写效率低于 Redis单机调试用文件生产环境用 Redis。这是我踩过坑后总结出来的经验。文件方案在多进程爬虫下会遇到竞争写入问题两个进程同时写同一个 Cookie 文件可能互相覆盖。而 Redis 天然是单线程写入加上EXPIRE命令还能自动管理过期时间简直是为 Cookie 存储量身定制的。Redis 存储的典型结构import redis import json r redis.Redis(hostlocalhost, port6379, db0) # 存储某个账号的 Cookie account user_001 cookie_dict { sessionid: abc123, csrftoken: xyz789, } r.hset(fcookies:{account}, mappingcookie_dict) r.expire(fcookies:{account}, 3600 * 8) # 8小时过期 # 读取 cookies r.hgetall(fcookies:{account}) cookie_str ; .join(f{k.decode()}{v.decode()} for k, v in cookies.items())这里有个细节Redis 的hset和expire之间并不是原子操作如果你在并发场景下读取可能读到还没设置过期时间的“中间态”。实际项目中可以用 Lua 脚本或者管道保证原子性。3.3 Cookie 失效与自动刷新机制爬虫稳定性的分水岭Cookie 是会失效的原因包括过期时间到了、服务端主动注销、账号被风控、IP 变化触发安全策略等。一个只登录一次就无限期使用的爬虫是不存在的所以在设计时需要把“Cookie 刷新”纳入整体架构。我在生产环境里用得最多的是一种简单但有效的“双层校验 自动重登”策略定义一个校验函数传入Session判断当前 Cookie 是否有效。判断方法不一定是访问登录态接口有时候直接访问一个需要登录才能看的页面看返回里有没有“请登录”的关键词即可。def is_login_valid(session, check_urlhttps://example.com/dashboard): resp session.get(check_url, timeout10) if resp.status_code 200 and 请登录 not in resp.text: return True return False在业务请求循环中每执行 N 次请求后调用一次校验函数。如果发现失效立即触发重新登录流程更新 Cookie 池。from datetime import datetime last_check_time datetime.now() def ensure_valid_session(session, account, check_interval300): global last_check_time now datetime.now() if (now - last_check_time).seconds check_interval: if not is_login_valid(session): session login_and_get_session(account) refresh_cookie_pool(session, account) last_check_time now return session重登时注意限速。频繁登录触发风控的概率极高建议在重登逻辑里加一个随机休眠比如time.sleep(random.uniform(3, 8))模拟人工登录节奏。这里再提醒一个容易忽略的细节Cookie 池里同一个账号不要同时供多个任务使用。如果两个爬虫进程同时携带同一份 Cookie 去请求同一个网站服务端很可能会因为请求频率异常触发账号封禁。要么给账号加锁要么按账号做任务分片。3.4 分布式爬虫场景下Cookie 池该怎么设计热搜词里有一个“分布式爬虫”和“藏宝阁 爬虫”同时出现说明不少人已经在实战分布式采集了。分布式爬虫的 Cookie 管理比单机复杂很多核心问题在于多个 worker 节点需要共享同一套账号 Cookie同时要避免并发冲突。我的推荐方案是基于 Redis 账号锁的结构账号列表存储Redis Set 中保存所有可用账号。Cookie 存储每个账号的 Cookie 存一个 Hash字段名是域名。租借机制worker 从 Redis 中SPOP取出一个账号使用期间加锁结束后归还。租约过期使用SET NX EX命令实现带超时的锁防止 worker 崩溃导致账号死锁。import redis import time import uuid r redis.Redis(hostlocalhost, port6379, db0) def acquire_account(account, lease_time300): lock_key faccount_lock:{account} token str(uuid.uuid4()) # SET NX EX 原子操作 ok r.set(lock_key, token, nxTrue, exlease_time) if ok: return token return None def release_account(account, token): lock_key faccount_lock:{account} # 使用 Lua 保证“先验证再删除”的原子性 script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end r.eval(script, 1, lock_key, token)这部分的实现难点不在代码而在并发思维。你永远要假设最坏情况某个 worker 节点可能拿到账号后突然崩溃锁必须有过期时间某个 Cookie 可能在请求过程中被服务端主动作废账号必须能被快速踢回池子并触发重新登录。4. Web 开发实战Cookie 的正确打开方式与安全防护前面聊的都是“怎么用 Python 去拿/带 Cookie”这一部分要反转视角——如果你是服务端开发者怎么正确地设置、校验和保护 Cookie。这对于写爬虫的人同等重要因为只有了解了服务端怎么设计你才能知道爬虫端怎么应对。4.1 Django 中 Cookie 的读写与签名机制Django 提供了非常完备的 Cookie 操作 API。设置 Cookie 用HttpResponse.set_cookie()读取用request.COOKIES.get()删除用HttpResponse.delete_cookie()。from django.http import HttpResponse def set_cookie_view(request): resp HttpResponse(Cookie 已设置) resp.set_cookie( username, python_crawler, max_age60 * 60 * 24, # 1天有效期 domain.example.com, # 跨子域共享 path/, secureTrue, # 仅 HTTPS httponlyTrue, # 禁止 JS 读取防 XSS samesiteLax, # 跨站请求限制 ) return respmax_age和expires的区别是新手容易搞混的地方。max_age是相对时间秒浏览器会把它换算成绝对过期时间expires是绝对时间datetime 对象。两者同时设置时现代浏览器以max_age为准但为了兼容老版本 Safari建议两个都设置。Django 的set_signed_cookie()是一个值得单独拎出来说的功能——它给 Cookie 的值加了一层签名防止客户端篡改。原理是服务端用SECRET_KEY对 Cookie 值生成一个 HMAC 签名附在后面客户端改动任何一个字符服务端在读取时验签就会失败。def set_signed_cookie_view(request): resp HttpResponse(已设置签名 Cookie) resp.set_signed_cookie(user_id, 12345, saltmy-salt, max_age60 * 60) return resp def read_signed_cookie_view(request): try: user_id request.get_signed_cookie(user_id, saltmy-salt) return HttpResponse(f用户 ID: {user_id}) except Exception as e: return HttpResponse(fCookie 校验失败: {e}, status400)这里有个细节值得留意salt参数的作用是防止同一个SECRET_KEY在不同场景下生成的签名被复用。比如你给user_id和username都用同一个 salt攻击者就可能把user_id的签名套到username上。所以每个业务字段的salt都要单独设计。4.2 Flask 中 Cookie 的操作方式make_response 是关键Flask 的 Cookie 操作与 Django 有一个显著不同你无法直接在视图函数中操作一个“隐式”的响应对象必须通过make_response()显式创建响应对象然后调用它的set_cookie()方法。from flask import Flask, make_response, request app Flask(__name__) app.route(/set) def set_cookie(): resp make_response(Cookie 已设置) resp.set_cookie( session_id, abc123, max_age60 * 60 * 24, httponlyTrue, secureTrue, samesiteLax, ) return resp app.route(/get) def get_cookie(): session_id request.cookies.get(session_id) return f得到 Session ID: {session_id} app.route(/delete) def delete_cookie(): resp make_response(Cookie 已删除) resp.delete_cookie(session_id) return respdelete_cookie()并不是真的从浏览器中删除 Cookie而是通过设置一个立即过期的同名 Cookie 来让浏览器“放弃”它。所以delete_cookie()的参数里必须包含与设置时相同的path和domain否则删除会无效。这个坑我曾经在线上环境踩过设置的path/删除时没传结果 Cookie 一直删不掉用户永远处于登录状态。Flask 中如果要实现类似 Django 的签名 Cookie可以用itsdangerous库。Flask 的session机制内部就使用了它所以直接引入成本很低from itsdangerous import URLSafeTimedSerializer serializer URLSafeTimedSerializer(secret-key, saltcookie-signature) # 签名 signed_value serializer.dumps({user_id: 12345}) # 验签max_age 控制最长有效期 try: data serializer.loads(signed_value, max_age60 * 60) except Exception as e: print(验签失败, e)4.3 企业级 Cookie 安全清单JWT、HttpOnly、SameSite 一个都不能少热搜词里有“企业级 web 开发”和“java controller 层如何防护 防止爬虫”可见不少人在做 Web 安全时都会把 Cookie 防护作为重点。这里我把服务端设置 Cookie 时的安全配置整理成一张对照表方便你直接抄作业安全项配置值防护目标HttpOnlyTrue防止 XSS 攻击通过document.cookie窃取会话SecureTrue防止 HTTP 明文传输中被截获SameSiteLax或Strict防止 CSRF 攻击Domain尽量不跨子域缩小 Cookie 影响范围Path尽量具体避免关键 Cookie 被无关路径携带过期时间越短越好减少被盗用后被长期使用的风险值的内容只存标识符不存明文敏感信息即使泄露损失可控关于 TokenJWT与 Cookie 的选择我的建议是新一代系统优先考虑 Token HttpOnly Cookie 的混合方案。将 JWT 放在 HttpOnly Cookie 中既利用了 Cookie 的自动携带特性又避免了将 Token 暴露给 JavaScript还能防止一部分 CSRF 攻击配合 SameSite。这套方案在前后端分离的项目里已经非常成熟。关于“防止爬虫”的思考热搜词里“java controller 层如何防护 防止爬虫”这个问题本质上和 Cookie 也有强关联。服务端可以通过检测 Cookie 的生成方式来判断是真人还是爬虫——比如真人浏览时会产生一系列合理的 Cookie 更新轨迹而爬虫往往是固定 Cookie。但反过来作为一个写爬虫的人你要意识到防爬没有一个银弹Cookie 只是其中的一环。真正稳健的爬虫策略不是“攻克”某个防护点而是模拟真实用户的完整行为链路——包括 Cookie 的生成时机、更新时机、过期时机。这算是跨视角的一个补充心得。5. 实战中的高频问题与排查技巧实录每个写爬虫或做 Web 开发的人都会在 Cookie 上栽过跟头。我把这些年遇到的典型问题整理成速查表附带排查思路和最终解决方案。5.1 Cookie 不生效为什么设置了你却没等到现象服务端明明返回了Set-Cookie但后续请求没有携带或者手动构造的 Cookie 发送了服务端却认为未登录。排查思路一步步来先打印原始响应头确认Set-Cookie真的存在resp session.post(https://example.com/login, datalogin_data) print(resp.headers.get(Set-Cookie))检查 Domain 和 Path。Cookie 只有在请求的域名和路径匹配时才会上送。比如你登录的是www.example.com拿到的 Cookie Domain 是.example.com这个对api.example.com是有效的但如果 Domain 是www.example.com那它就不会被携带到api.example.com上。检查 Secure 标志。如果Set-Cookie中带了Secure属性那它只在 HTTPS 请求中上送。如果你用 HTTP 访问测试环境这个 Cookie 永远不会被带过去。检查 requests 是否忽略了 Cookie。有一种情况你直接通过headers{Cookie: ...}设置了 Cookie但底层的CookieJar里没有对应记录在后续的自动重定向或跨域跳转中这个手动 Header 可能被丢弃。这种情况建议改用session.cookies.set()的方式。5.2 浏览器开发者工具看不到 Cookie并非代码问题热搜词里有“chome 开发者工具没有 cookie”这个问题我见过很多次。排查方向有两个第一你查看的位置不对。开发者工具里看 Cookie 有两个入口Network面板中某个具体请求的Headers标签页里有Request Headers的Cookie字段Application面板里有Storage → Cookies → 你的域名。如果你在Network面板的Payload或Preview里找自然找不到。第二当前浏览器配置了“阻止所有 Cookie”。在 Chrome 的设置 → 隐私和安全 → Cookie 及其他网站数据里如果选择了“阻止所有第三方 Cookie”某些场景下连第一方 Cookie 也会受影响。把站点加入白名单即可。还有一个容易被忽略的细节Chrome 的「隐身模式」默认允许 Cookie但不允许持久化 Cookie因为关闭窗口即清空。所以如果你测试时勾选了隐身模式切回常规模式后 Cookie 文件可能已经清理了。5.3 Chrome 无法导出 Cookie换条路走通“360 浏览器怎么导出 cookie”和“chrome 开发者工具没有 cookie”这两个热搜词背后其实是同一个需求某些工具需要浏览器登录态的 Cookie。最直接的办法是用浏览器扩展如 EditThisCookie但如果你不想装扩展另一个稳定方案是用selenium自动登录后获取 Cookie。from selenium import webdriver from selenium.webdriver.common.by import By import time driver webdriver.Chrome() driver.get(https://example.com/login) driver.find_element(By.NAME, username).send_keys(your_account) driver.find_element(By.NAME, password).send_keys(your_password) driver.find_element(By.TAG_NAME, button).click() time.sleep(3) # 等页面跳转 cookies driver.get_cookies() for cookie in cookies: print(f{cookie[name]}{cookie[value]})这里有个额外的坑如果登录过程有滑块验证码或人脸验证selenium方案也搞不定必须人工介入。这叫做“半自动登录”在爬虫领域很常见开着浏览器让真人完成验证码部分代码自动接管后续请求。5.4 requests 丢失 Cookie 的幕后黑手重定向与跨域requests.Session在自动重定向时通常能保留 Cookie但有一种场景会丢从http://a.com重定向到http://b.com然后b.com又设置了 Domain 为b.com的新 Cookie。此时a.com的 Cookie 对新域没有意义requests不会把它带过去。这不是 Bug而是行为正确。解决思路如果业务场景需要跨域共享登录态要么在主域根下设置 Domain要么改为服务端 Token 方案把 Token 作为查询参数或自定义 Header 在跨域跳转中传递。我之前排查过一个诡异问题requests在某些环境里会丢掉Path为/的 Cookie。后来发现是代码里用了requests.get()而非session.get()导致 Cookie 没有经过同一个Session的 Jar 管理。这个问题非常值得自查——你在代码的哪里发起了请求Cookie 就在哪里管理不要混用裸请求和 Session 请求。6. 从爬虫到 Web 开发Cookie 操作的心法总结写到这里我把这些年的核心体会浓缩一下。Cookie 操作在所有语言里都遵循同一套底层逻辑读请求头、写响应头、存储和过期。Python 只是恰好提供了多种工具让你能在不同场景下优雅地操作它。http.cookiejar是基础requests.Session是主力selenium是补漏Django/Flask 的 Cookie API 是开发侧的落点。我最后再分享一个小技巧。写爬虫的人一定要学会用手机端的 Cookie 来反查 Web 端的问题。比如热搜词里“网易云 cookie 手机怎么获取”这种问题本质上就是想在非浏览器环境下获取 Token。遇到这种情况我的习惯是先用抓包工具如 Charles 或 Fiddler抓取移动端 HTTP 请求直接看请求头里的Cookie字段或Authorization字段。因为移动端 App 的请求头往往比浏览器的更简洁、更直接能帮你快速定位到真正在用的凭证格式然后再回 Python 代码里构造对应的请求。Cookie 这东西单独看是个小知识点但它串联着 HTTP 协议、会话管理、安全防护、爬虫工程化、Web 框架设计这么多环节值得花时间彻底搞懂。希望这篇文章能帮你把这条链路打通后续遇到任何与 Cookie 相关的报错都能冷静地一步步排查。