1. 先搞清楚cookie是什么再动手获取先说个最常见的场景。你打开某个网站登录自己的账号关掉浏览器第二天再打开发现居然还是登录状态。这个“记住你”的东西就是cookie。但如果你以为cookie只是一串“登录凭证”那就把它想简单了。我见过太多人在项目里栽跟头就是因为没搞懂cookie的结构拿到手也不知道哪些字段有用、哪些是干扰项。1.1 cookie的真实身份绝不是“一串字符”这么简单cookie本质上是一小段文本由服务器在HTTP响应头里通过Set-Cookie字段发给浏览器浏览器收到后按照域名、路径、过期时间等信息存下来。后续同一个域名下的每一次请求浏览器都会自动把对应的cookie放进Cookie请求头里服务器一看这个cookie就知道“这是之前那个登录过的用户”。从技术角度拆开看一条完整的cookie最少包含下面这几块namevaluecookie的核心就像一把钥匙和锁的配对。服务器凭这个值认出你是谁。Domain这个cookie作用在哪个域名下。比如Domain.example.com表示所有example.com的子域名都会带上它。Path限定在哪个路径下生效。默认是/也就是整个域名下都生效。Expires/Max-Age过期时间。没有这个字段的就是会话cookie浏览器一关就没了有具体时间的则是持久化cookie。HttpOnly标记了这个属性的cookie不能被JavaScript读取只能由浏览器在HTTP请求时自动带上主要用来防XSS窃取。Secure只允许在HTTPS连接下传输。SameSite控制跨站请求时是否携带cookie跟CSRF防护强相关。你去看浏览器里的cookie会看到一大堆名称奇怪的字段比如sessionid、token、_ga、Hm_lvt_xxx、JSESSIONID等等。这里面有的负责登录态有的负责统计埋点有的只是广告追踪。真正要抓的时候先搞清楚哪些是关键值能省掉后面一大堆麻烦。1.2 两种主流cookie会话cookie与持久化cookie这一块特别容易混淆。简单说会话cookie没有Expires或者Max-Age字段浏览器关闭后自动消失。很多网站的登录态用的是会话cookie所以你会遇到“关了浏览器就要重新登录”的情况。反过来说那些“记住我”功能的网站会把登录信息写进持久化cookie给你一个很长的有效期比如7天、30天。这个区别在做自动化的时候非常关键。用程序去获取cookie如果只拿到会话cookie脚本一重启或者环境一换cookie就失效了。你必须要检查有没有拿到持久化cookie或者主动模拟“记住我”选项否则后面写好的采集脚本、签到脚本第二天早上起来准报错。1.3 为什么你需要手动获取cookie而不是代码自动登录我猜点进来看这篇文章的多数是被“自动登录”折磨过的人。直接写代码模拟登录看起来是一条大路实际走起来遍地坑验证码、滑块、短信验证、设备指纹、风控策略哪一个都能卡你半天。所以更务实的思路是手动在浏览器里登录一次拿到登录后的cookie再把这个cookie喂给脚本或测试工具。这个方案只依赖最终结果不碰登录过程稳定性高出好几个级别。另外还有一些情况比如目标站点的登录过程涉及扫码、第三方OAuth跳转代码模拟的成本极高手动获取cookie几乎是唯一高效的选择。这个思路我就直接说结论凡是登录流程复杂的站点优先用手动获取cookie而不是硬写自动登录。2. 获取前的准备域名筛选与工具选择搞清楚原理之后别急着打开网页就开抓。先花两分钟想清楚目标后面能少返工。我的习惯是先把下面几件事定下来再进入实操。2.1 先确定要抓哪个域名下的cookie很多网站会同时加载好几个域名下的cookie比如主站的example.com、静态资源服务器的static.example.com、第三方统计的google-analytics.com之类。你写脚本请求接口的时候只需要带上接口所属域名的cookie其他的带过去反而可能触发风控。怎么判断要抓哪个域名最简单的办法打开浏览器开发者工具F12切到Network面板刷新页面看你要调用的那个接口请求然后看这个请求的Cookie请求头里面出现的就是当前真正传出去的cookie。这里也要提醒一下如果你用的工具支持设置cookie的作用域尽量把Domain限定明确。之前有朋友做网易云音乐网页版的接口调试他把所有域名的cookie一股脑复制进脚本结果接口反复报错排查半天发现是带了别的域下的一个过期cookie干扰了请求头里的字段。2.2 推荐工具Chrome DevTools 与专用扩展怎么选获取cookie的工具市面上数不清但我实践下来主用的就三类浏览器自带的DevToolsApplication和Network面板最稳、最通用不依赖任何第三方插件适合任何场景的精确抓取。浏览器扩展比如EditThisCookie、Cookie-Editor适合快速导出当前域名下的全部cookie格式选择多JSON、Netscape、Header String。自动化脚本比如Python的Selenium、Playwright、DrissionPage适合批量处理或要把cookie动态注入到脚本里的场景。我的经验是**如果只是临时用一次直接用DevTools就够了如果是长期采集项目里要维护cookie建议用扩展导出JSON格式再配合程序读取如果cookie会频繁变化就上自动化方案。**三种工具各有定位别一个方案用到底。2.3 准备工作清单动手之前确认下面几项都准备好了能少走不少弯路一台能稳定联网的电脑建议用Chrome或者Edge浏览器内核一样操作步骤通用。提前注册好目标网站的账号保证可以完成登录操作。明确你最终要把cookie用在哪是写在Python脚本里、Postman/JMeter测试工具里还是浏览器的另一个环境里。用途不同导出的字段和格式要求就不一样。如果目标网站有反爬策略建议先用常用IP和习惯的设备操作别一上来就挂代理或者换乱七八糟的网络环境容易触发风控。3. 核心实操用浏览器开发者工具获取cookie这一部分是全篇的重点我会把操作步骤拆到每一步跟着做就能拿到结果。我自己给很多朋友演示过这个过程新手最容易踩的坑也会一并标出来。3.1 第一步打开DevTools并进入Application面板用Chrome打开目标网站先不要登录直接按F12进入开发者工具然后顶部菜单栏找到Application中文版叫“应用”左侧菜单里找到Cookies点击展开底下会列出当前页面涉及的所有域名。这个面板展示的信息非常全每条cookie的名称、值、Domain、Path、Expires、Size、HttpOnly、Secure、SameSite一目了然。这里要记住你在这个面板里看到的只是当前这个标签页能访问到的cookie。某些安全策略下跨域iframe里的cookie不会显示在这里就需要换Network的方法。第一次进来的朋友看到一堆cookie名称别慌。它们不会全是登录凭证很多是统计、埋点类的。先确认你目标接口的域名是哪个只关心这个域名下的cookie就行。3.2 第二步登录目标站点并观察cookie的变化现在保持Application面板打开切回页面开始正常登录。登录完成后回到Application面板点一下当前域名再点一下左下角的刷新按钮或者直接在当前页面按F5刷新你就能看到cookie列表发生了变化。关键点来了**对比登录前后新增了哪些cookie这些新增的才是真正的登录凭证。**比如很多网站登录后会多出sessionid、token、remember_me之类的字段。如果你发现登录后cookie没有变化说明这个站点可能用的是localStorage、sessionStorage或者Authorization头来做登录态管理cookie这条路就不是主要凭证了。这里要特别提醒登录的时候千万别勾选“记住我”选项前的预期问题。有些站点勾选后cookie有效期会拉得很长适合采集有些站点反而因为勾选了记住我触发了额外的二次验证流程导致拿到的cookie状态异常。我的习惯是先不勾拿到基础会话cookie如果发现很快失效再回头试试勾上。3.3 第三步从Network面板精准抓取请求头中的CookieApplication面板适合查看完整的cookie信息但如果你想把cookie原封不动地用在HTTP请求里我强烈建议你从Network面板抓。刷新页面在Network面板里找到任意一个接口请求点开它在Headers标签页里找到Request Headers区域里面的Cookie字段就是一整串浏览器实际发送的cookie。这一整串copy下来可以直接黏贴到请求头里。这也是Postman、JMeter、Python requests里最常见的用法。用这种方式有个好处你看到的是浏览器真正发出去的cookie不会出现“Application面板里明明有但请求里没带上”的尴尬。比如有些cookie是第三方iframe里的或者JS里设置了但没生效的在Network面板里一抓便知。3.4 第四步处理httpOnly标志的cookie很多人会在这里卡住。Application面板里可以看到若干条cookie但某些关键字段显示HttpOnly勾选着。这意味着JavaScript代码里用document.cookie读不到它不过这并不妨碍你从Network面板的请求头里拿到完整值。所以**如果你要拿的cookie值正好是httpOnly的别试图用脚本在页面里执行JS去读直接去Network面板的请求头里搜。**这是一条最实用的经验。4. 进阶方案用脚本批量提取与备份cookie浏览器里手动复制cookie只能解决一次性需求。如果每天都要更新cookie或者一次性要操作多个账号就必须上脚本了。我自己在采集项目中用的方案在这部分完整分享出来。4.1 Python加Selenium/DrissionPage自动提取先说我比较推荐的一个组合Python加DrissionPage。这个库对国内网页的适配比Selenium顺滑很多而且它内置了读取浏览器cookie的功能不用自己拼请求头。核心逻辑分三步启动浏览器、登录目标站、读取cookie并保存到文件。from DrissionPage import ChromiumPage page ChromiumPage() # 访问目标网站 page.get(https://example.com) # 这里手动登录或者程序里完成登录操作 input(请在弹出的浏览器中完成登录然后按回车继续...) # 获取当前域名下的所有cookie cookies page.cookies(as_dictFalse) for cookie in cookies: print(cookie) # 保存成Netscape格式方便curl或脚本使用 with open(cookies.txt, w, encodingutf-8) as f: f.write(# Netscape HTTP Cookie File\n) for c in cookies: domain c.get(domain, example.com) include_sub TRUE if domain.startswith(.) else FALSE path c.get(path, /) secure TRUE if c.get(secure) else FALSE expires str(int(c.get(expires, 0))) name c.get(name, ) value c.get(value, ) f.write(f{domain}\t{include_sub}\t{path}\t{secure}\t{expires}\t{name}\t{value}\n) print(cookie已保存)如果你更习惯Selenium也可以用driver.get_cookies()方法拿到的是一组字典列表手动转成Netscape格式或Header格式再保存。区别不大只是DrissionPage省掉了WebDriver的配置问题。4.2 浏览器扩展一键导出配合外部脚本使用不想写代码的话就用扩展。以Cookie-Editor为例装好后打开目标站点点击扩展图标能看到当前站点所有cookie。它支持几种导出格式我最常用的是Header String和JSON。Header String格式可以直接作为HTTP请求头的Cookie字段值适合丢进Postman、JMeter或者requests脚本里。JSON格式适合程序化处理比如把value取出来拼成字典。这里有几个细节容易踩扩展导出的cookie包含的是当前站点所有可访问的cookie可能混合了多个域的。用的时候要过滤。如果导出的cookie里有SameSiteNone注意确认目标接口是否要求带Secure属性否则部分环境里请求会异常。扩展在隐身模式下默认禁用如果你需要在无痕环境里操作提前到扩展管理里开启“在无痕模式下启用”。4.3 cookie失效了先检查这几个地方很多人的脚本“昨天还能跑今天突然报错”。cookie失效是必然的问题的关键是怎么快速定位原因。按我的排查顺序先看这几点过期时间到了cookie里如果有关键字段的Expires已经过期直接重新登录拿新的。IP或UA变了不少网站会把cookie跟IP、User-Agent绑定。你用家里的IP拿到的cookie换到服务器上跑直接失效。登录态被踢同账号在其他地方登录旧cookie经常会失效。尤其是视频、社交、电商类站点单点登录策略很常见。签名参数过期有些cookie里的值本身就是带时间戳的签名超过一定时间服务器直接拒绝跟cookie本身过期与否没关系。我一个做抖音来客运营的朋友之前就遇到过cookie持久化失效的问题。后来他把拿cookie的环境浏览器指纹、UA、IP固定下来每次有变化就重新获取问题就消失了。说白了cookie不是一劳永逸的东西它是有生命周期的把它当作需要定期维护的资源来管理心态就对了。5. 常见问题与避坑实录这个部分我从实际经历里挑了一些典型问题做成速查表方便你遇到报错的时候快速对照。现象常见原因解决思路请求返回未登录提示cookie漏了某个关键字段到Network面板里对比浏览器真实请求头补全字段脚本请求被风控拦截IP、UA、Cookie不匹配保持获取cookie和使用cookie时的环境一致导入cookie后立刻失效登录态被单点登录策略挤出检查是否在其他地方登录过目标账号Cookie里找不到登录字段站点用的是localStorage/token机制改用Network面板抓Authorization头处理同一份cookiePostman能用但代码不行代码里header格式或编码问题先打印完整请求头对比差异用JMeter设置cookie后无效果没配置HTTP Cookie Manager或cookie作用域不对添加HTTP Cookie Manager并确认Domain匹配5.1 为什么Cookie里总出现一堆看不懂的字段很多网站的cookie是多方注入的有自己服务器种的有JS脚本种的还有广告联盟、统计工具种的。比如百度统计、谷歌分析的_ga、_gid这些字段不影响登录态复制的时候忽略掉就好。判断一个cookie字段是否核心我的经验是看它跟接口请求的关系把某个字段从请求头里删掉接口是否返回异常。用这个方式来试错比靠名字猜靠谱得多。但注意这种方式只在你自己的账号上、合法合规的测试场景里用。5.2 换设备、换IP、换浏览器cookie全变了这一点我需要单独拿出来说因为它坑过很多人。不要以为cookie是一串固定的值拿到就能用一辈子。很多网站会对cookie进行多维度绑定IP地址变了cookie直接失效User-Agent变了cookie也失效浏览器指纹变了cookie同样可能失效时区、语言设置变了部分站点也会做二次校验所以我在做采集项目时会固定一个执行环境固定的VPS或家用宽带出口IP、固定的浏览器UA、固定的语言设置尽量模拟真实用户访问习惯。这样cookie的存活时间会大幅延长。5.3 签名算法、双token、滑动验证光有cookie还不够聊点更深的东西。现在稍微有点规模的站点已经不满足于只用cookie管理登录态了。常见做法是cookie配合payload里的动态token一起使用。比如登录后服务器返回一个access_token放在cookie里同时前端的每个接口请求还要在请求体里带一个由页面内JS计算出来的校验参数。这种情况单纯复制cookie就不够了。你需要去分析接口的完整请求逻辑看看除了cookie之外还有哪些参数是动态生成的。我在一篇讲网易云音乐网页版抓cookie的文章里就提到过它的某些接口除了要cookie还要在请求里带加密参数直接从浏览器copy cookie丢给脚本大概率还是失败。正确的姿势是用Playwright或DrissionPage这类能控制真实浏览器的自动化工具让浏览器自己去完成JS计算和请求脚本只负责拿到最终结果。这比自己逆向加密算法快太多了。5.4 安全红线cookie泄露与XSS这些事千万别干最后说点正经的。cookie是数字身份凭证尤其登录态的cookie等于你账号的一把备用钥匙。拿到它的人可以直接冒充你登录网站。我从入行第一天起就记住一条底线自己账号的cookie可以调试、可以测试但绝不能把别人的cookie拿来干坏事也绝不要把包含敏感信息的cookie到处乱发、贴截图。以前很多人中招的XSS攻击本质就是攻击者在输入框里注入了一段恶意JS让浏览器把当前站点的cookie尤其是没设置HttpOnly的发送到攻击者的服务器上。做测试的时候我会专门给cookie设置好HttpOnly、Secure、SameSite属性目的就是降低被窃取风险。如果你是给公司的项目做脚本更要注意cookie的存储安全。不要硬编码在代码里不要提交到公开的Git仓库建议的做法是把cookie放到本地配置文件或环境变量里脚本运行时动态读取。真要放代码里也要确保代码仓库是私有的并且定期轮换cookie。安全这件事前期做得好后面能省心一万倍。另外如果你遇到某个站点频繁要求重新登录先别急着怪cookie失效看看是不是自己浏览器的清理策略太激进或者是站点的单点登录逻辑有变化。用我之前说的排查顺序一步步来一般10分钟以内就能定位到问题。
如何正确获取Cookie？浏览器开发者工具与脚本提取全指南
1. 先搞清楚cookie是什么再动手获取先说个最常见的场景。你打开某个网站登录自己的账号关掉浏览器第二天再打开发现居然还是登录状态。这个“记住你”的东西就是cookie。但如果你以为cookie只是一串“登录凭证”那就把它想简单了。我见过太多人在项目里栽跟头就是因为没搞懂cookie的结构拿到手也不知道哪些字段有用、哪些是干扰项。1.1 cookie的真实身份绝不是“一串字符”这么简单cookie本质上是一小段文本由服务器在HTTP响应头里通过Set-Cookie字段发给浏览器浏览器收到后按照域名、路径、过期时间等信息存下来。后续同一个域名下的每一次请求浏览器都会自动把对应的cookie放进Cookie请求头里服务器一看这个cookie就知道“这是之前那个登录过的用户”。从技术角度拆开看一条完整的cookie最少包含下面这几块namevaluecookie的核心就像一把钥匙和锁的配对。服务器凭这个值认出你是谁。Domain这个cookie作用在哪个域名下。比如Domain.example.com表示所有example.com的子域名都会带上它。Path限定在哪个路径下生效。默认是/也就是整个域名下都生效。Expires/Max-Age过期时间。没有这个字段的就是会话cookie浏览器一关就没了有具体时间的则是持久化cookie。HttpOnly标记了这个属性的cookie不能被JavaScript读取只能由浏览器在HTTP请求时自动带上主要用来防XSS窃取。Secure只允许在HTTPS连接下传输。SameSite控制跨站请求时是否携带cookie跟CSRF防护强相关。你去看浏览器里的cookie会看到一大堆名称奇怪的字段比如sessionid、token、_ga、Hm_lvt_xxx、JSESSIONID等等。这里面有的负责登录态有的负责统计埋点有的只是广告追踪。真正要抓的时候先搞清楚哪些是关键值能省掉后面一大堆麻烦。1.2 两种主流cookie会话cookie与持久化cookie这一块特别容易混淆。简单说会话cookie没有Expires或者Max-Age字段浏览器关闭后自动消失。很多网站的登录态用的是会话cookie所以你会遇到“关了浏览器就要重新登录”的情况。反过来说那些“记住我”功能的网站会把登录信息写进持久化cookie给你一个很长的有效期比如7天、30天。这个区别在做自动化的时候非常关键。用程序去获取cookie如果只拿到会话cookie脚本一重启或者环境一换cookie就失效了。你必须要检查有没有拿到持久化cookie或者主动模拟“记住我”选项否则后面写好的采集脚本、签到脚本第二天早上起来准报错。1.3 为什么你需要手动获取cookie而不是代码自动登录我猜点进来看这篇文章的多数是被“自动登录”折磨过的人。直接写代码模拟登录看起来是一条大路实际走起来遍地坑验证码、滑块、短信验证、设备指纹、风控策略哪一个都能卡你半天。所以更务实的思路是手动在浏览器里登录一次拿到登录后的cookie再把这个cookie喂给脚本或测试工具。这个方案只依赖最终结果不碰登录过程稳定性高出好几个级别。另外还有一些情况比如目标站点的登录过程涉及扫码、第三方OAuth跳转代码模拟的成本极高手动获取cookie几乎是唯一高效的选择。这个思路我就直接说结论凡是登录流程复杂的站点优先用手动获取cookie而不是硬写自动登录。2. 获取前的准备域名筛选与工具选择搞清楚原理之后别急着打开网页就开抓。先花两分钟想清楚目标后面能少返工。我的习惯是先把下面几件事定下来再进入实操。2.1 先确定要抓哪个域名下的cookie很多网站会同时加载好几个域名下的cookie比如主站的example.com、静态资源服务器的static.example.com、第三方统计的google-analytics.com之类。你写脚本请求接口的时候只需要带上接口所属域名的cookie其他的带过去反而可能触发风控。怎么判断要抓哪个域名最简单的办法打开浏览器开发者工具F12切到Network面板刷新页面看你要调用的那个接口请求然后看这个请求的Cookie请求头里面出现的就是当前真正传出去的cookie。这里也要提醒一下如果你用的工具支持设置cookie的作用域尽量把Domain限定明确。之前有朋友做网易云音乐网页版的接口调试他把所有域名的cookie一股脑复制进脚本结果接口反复报错排查半天发现是带了别的域下的一个过期cookie干扰了请求头里的字段。2.2 推荐工具Chrome DevTools 与专用扩展怎么选获取cookie的工具市面上数不清但我实践下来主用的就三类浏览器自带的DevToolsApplication和Network面板最稳、最通用不依赖任何第三方插件适合任何场景的精确抓取。浏览器扩展比如EditThisCookie、Cookie-Editor适合快速导出当前域名下的全部cookie格式选择多JSON、Netscape、Header String。自动化脚本比如Python的Selenium、Playwright、DrissionPage适合批量处理或要把cookie动态注入到脚本里的场景。我的经验是**如果只是临时用一次直接用DevTools就够了如果是长期采集项目里要维护cookie建议用扩展导出JSON格式再配合程序读取如果cookie会频繁变化就上自动化方案。**三种工具各有定位别一个方案用到底。2.3 准备工作清单动手之前确认下面几项都准备好了能少走不少弯路一台能稳定联网的电脑建议用Chrome或者Edge浏览器内核一样操作步骤通用。提前注册好目标网站的账号保证可以完成登录操作。明确你最终要把cookie用在哪是写在Python脚本里、Postman/JMeter测试工具里还是浏览器的另一个环境里。用途不同导出的字段和格式要求就不一样。如果目标网站有反爬策略建议先用常用IP和习惯的设备操作别一上来就挂代理或者换乱七八糟的网络环境容易触发风控。3. 核心实操用浏览器开发者工具获取cookie这一部分是全篇的重点我会把操作步骤拆到每一步跟着做就能拿到结果。我自己给很多朋友演示过这个过程新手最容易踩的坑也会一并标出来。3.1 第一步打开DevTools并进入Application面板用Chrome打开目标网站先不要登录直接按F12进入开发者工具然后顶部菜单栏找到Application中文版叫“应用”左侧菜单里找到Cookies点击展开底下会列出当前页面涉及的所有域名。这个面板展示的信息非常全每条cookie的名称、值、Domain、Path、Expires、Size、HttpOnly、Secure、SameSite一目了然。这里要记住你在这个面板里看到的只是当前这个标签页能访问到的cookie。某些安全策略下跨域iframe里的cookie不会显示在这里就需要换Network的方法。第一次进来的朋友看到一堆cookie名称别慌。它们不会全是登录凭证很多是统计、埋点类的。先确认你目标接口的域名是哪个只关心这个域名下的cookie就行。3.2 第二步登录目标站点并观察cookie的变化现在保持Application面板打开切回页面开始正常登录。登录完成后回到Application面板点一下当前域名再点一下左下角的刷新按钮或者直接在当前页面按F5刷新你就能看到cookie列表发生了变化。关键点来了**对比登录前后新增了哪些cookie这些新增的才是真正的登录凭证。**比如很多网站登录后会多出sessionid、token、remember_me之类的字段。如果你发现登录后cookie没有变化说明这个站点可能用的是localStorage、sessionStorage或者Authorization头来做登录态管理cookie这条路就不是主要凭证了。这里要特别提醒登录的时候千万别勾选“记住我”选项前的预期问题。有些站点勾选后cookie有效期会拉得很长适合采集有些站点反而因为勾选了记住我触发了额外的二次验证流程导致拿到的cookie状态异常。我的习惯是先不勾拿到基础会话cookie如果发现很快失效再回头试试勾上。3.3 第三步从Network面板精准抓取请求头中的CookieApplication面板适合查看完整的cookie信息但如果你想把cookie原封不动地用在HTTP请求里我强烈建议你从Network面板抓。刷新页面在Network面板里找到任意一个接口请求点开它在Headers标签页里找到Request Headers区域里面的Cookie字段就是一整串浏览器实际发送的cookie。这一整串copy下来可以直接黏贴到请求头里。这也是Postman、JMeter、Python requests里最常见的用法。用这种方式有个好处你看到的是浏览器真正发出去的cookie不会出现“Application面板里明明有但请求里没带上”的尴尬。比如有些cookie是第三方iframe里的或者JS里设置了但没生效的在Network面板里一抓便知。3.4 第四步处理httpOnly标志的cookie很多人会在这里卡住。Application面板里可以看到若干条cookie但某些关键字段显示HttpOnly勾选着。这意味着JavaScript代码里用document.cookie读不到它不过这并不妨碍你从Network面板的请求头里拿到完整值。所以**如果你要拿的cookie值正好是httpOnly的别试图用脚本在页面里执行JS去读直接去Network面板的请求头里搜。**这是一条最实用的经验。4. 进阶方案用脚本批量提取与备份cookie浏览器里手动复制cookie只能解决一次性需求。如果每天都要更新cookie或者一次性要操作多个账号就必须上脚本了。我自己在采集项目中用的方案在这部分完整分享出来。4.1 Python加Selenium/DrissionPage自动提取先说我比较推荐的一个组合Python加DrissionPage。这个库对国内网页的适配比Selenium顺滑很多而且它内置了读取浏览器cookie的功能不用自己拼请求头。核心逻辑分三步启动浏览器、登录目标站、读取cookie并保存到文件。from DrissionPage import ChromiumPage page ChromiumPage() # 访问目标网站 page.get(https://example.com) # 这里手动登录或者程序里完成登录操作 input(请在弹出的浏览器中完成登录然后按回车继续...) # 获取当前域名下的所有cookie cookies page.cookies(as_dictFalse) for cookie in cookies: print(cookie) # 保存成Netscape格式方便curl或脚本使用 with open(cookies.txt, w, encodingutf-8) as f: f.write(# Netscape HTTP Cookie File\n) for c in cookies: domain c.get(domain, example.com) include_sub TRUE if domain.startswith(.) else FALSE path c.get(path, /) secure TRUE if c.get(secure) else FALSE expires str(int(c.get(expires, 0))) name c.get(name, ) value c.get(value, ) f.write(f{domain}\t{include_sub}\t{path}\t{secure}\t{expires}\t{name}\t{value}\n) print(cookie已保存)如果你更习惯Selenium也可以用driver.get_cookies()方法拿到的是一组字典列表手动转成Netscape格式或Header格式再保存。区别不大只是DrissionPage省掉了WebDriver的配置问题。4.2 浏览器扩展一键导出配合外部脚本使用不想写代码的话就用扩展。以Cookie-Editor为例装好后打开目标站点点击扩展图标能看到当前站点所有cookie。它支持几种导出格式我最常用的是Header String和JSON。Header String格式可以直接作为HTTP请求头的Cookie字段值适合丢进Postman、JMeter或者requests脚本里。JSON格式适合程序化处理比如把value取出来拼成字典。这里有几个细节容易踩扩展导出的cookie包含的是当前站点所有可访问的cookie可能混合了多个域的。用的时候要过滤。如果导出的cookie里有SameSiteNone注意确认目标接口是否要求带Secure属性否则部分环境里请求会异常。扩展在隐身模式下默认禁用如果你需要在无痕环境里操作提前到扩展管理里开启“在无痕模式下启用”。4.3 cookie失效了先检查这几个地方很多人的脚本“昨天还能跑今天突然报错”。cookie失效是必然的问题的关键是怎么快速定位原因。按我的排查顺序先看这几点过期时间到了cookie里如果有关键字段的Expires已经过期直接重新登录拿新的。IP或UA变了不少网站会把cookie跟IP、User-Agent绑定。你用家里的IP拿到的cookie换到服务器上跑直接失效。登录态被踢同账号在其他地方登录旧cookie经常会失效。尤其是视频、社交、电商类站点单点登录策略很常见。签名参数过期有些cookie里的值本身就是带时间戳的签名超过一定时间服务器直接拒绝跟cookie本身过期与否没关系。我一个做抖音来客运营的朋友之前就遇到过cookie持久化失效的问题。后来他把拿cookie的环境浏览器指纹、UA、IP固定下来每次有变化就重新获取问题就消失了。说白了cookie不是一劳永逸的东西它是有生命周期的把它当作需要定期维护的资源来管理心态就对了。5. 常见问题与避坑实录这个部分我从实际经历里挑了一些典型问题做成速查表方便你遇到报错的时候快速对照。现象常见原因解决思路请求返回未登录提示cookie漏了某个关键字段到Network面板里对比浏览器真实请求头补全字段脚本请求被风控拦截IP、UA、Cookie不匹配保持获取cookie和使用cookie时的环境一致导入cookie后立刻失效登录态被单点登录策略挤出检查是否在其他地方登录过目标账号Cookie里找不到登录字段站点用的是localStorage/token机制改用Network面板抓Authorization头处理同一份cookiePostman能用但代码不行代码里header格式或编码问题先打印完整请求头对比差异用JMeter设置cookie后无效果没配置HTTP Cookie Manager或cookie作用域不对添加HTTP Cookie Manager并确认Domain匹配5.1 为什么Cookie里总出现一堆看不懂的字段很多网站的cookie是多方注入的有自己服务器种的有JS脚本种的还有广告联盟、统计工具种的。比如百度统计、谷歌分析的_ga、_gid这些字段不影响登录态复制的时候忽略掉就好。判断一个cookie字段是否核心我的经验是看它跟接口请求的关系把某个字段从请求头里删掉接口是否返回异常。用这个方式来试错比靠名字猜靠谱得多。但注意这种方式只在你自己的账号上、合法合规的测试场景里用。5.2 换设备、换IP、换浏览器cookie全变了这一点我需要单独拿出来说因为它坑过很多人。不要以为cookie是一串固定的值拿到就能用一辈子。很多网站会对cookie进行多维度绑定IP地址变了cookie直接失效User-Agent变了cookie也失效浏览器指纹变了cookie同样可能失效时区、语言设置变了部分站点也会做二次校验所以我在做采集项目时会固定一个执行环境固定的VPS或家用宽带出口IP、固定的浏览器UA、固定的语言设置尽量模拟真实用户访问习惯。这样cookie的存活时间会大幅延长。5.3 签名算法、双token、滑动验证光有cookie还不够聊点更深的东西。现在稍微有点规模的站点已经不满足于只用cookie管理登录态了。常见做法是cookie配合payload里的动态token一起使用。比如登录后服务器返回一个access_token放在cookie里同时前端的每个接口请求还要在请求体里带一个由页面内JS计算出来的校验参数。这种情况单纯复制cookie就不够了。你需要去分析接口的完整请求逻辑看看除了cookie之外还有哪些参数是动态生成的。我在一篇讲网易云音乐网页版抓cookie的文章里就提到过它的某些接口除了要cookie还要在请求里带加密参数直接从浏览器copy cookie丢给脚本大概率还是失败。正确的姿势是用Playwright或DrissionPage这类能控制真实浏览器的自动化工具让浏览器自己去完成JS计算和请求脚本只负责拿到最终结果。这比自己逆向加密算法快太多了。5.4 安全红线cookie泄露与XSS这些事千万别干最后说点正经的。cookie是数字身份凭证尤其登录态的cookie等于你账号的一把备用钥匙。拿到它的人可以直接冒充你登录网站。我从入行第一天起就记住一条底线自己账号的cookie可以调试、可以测试但绝不能把别人的cookie拿来干坏事也绝不要把包含敏感信息的cookie到处乱发、贴截图。以前很多人中招的XSS攻击本质就是攻击者在输入框里注入了一段恶意JS让浏览器把当前站点的cookie尤其是没设置HttpOnly的发送到攻击者的服务器上。做测试的时候我会专门给cookie设置好HttpOnly、Secure、SameSite属性目的就是降低被窃取风险。如果你是给公司的项目做脚本更要注意cookie的存储安全。不要硬编码在代码里不要提交到公开的Git仓库建议的做法是把cookie放到本地配置文件或环境变量里脚本运行时动态读取。真要放代码里也要确保代码仓库是私有的并且定期轮换cookie。安全这件事前期做得好后面能省心一万倍。另外如果你遇到某个站点频繁要求重新登录先别急着怪cookie失效看看是不是自己浏览器的清理策略太激进或者是站点的单点登录逻辑有变化。用我之前说的排查顺序一步步来一般10分钟以内就能定位到问题。
