1. 项目概述与核心价值最近在折腾一些自动化流程需要对接“接龙管家”这个工具来获取一些数据。手动操作太费时自然就想到了用PythonSelenium这套经典的自动化组合拳。但在实际操作中我发现获取Token这个核心环节远不止“模拟登录然后从Cookie里拿”这么简单。不同的场景、不同的需求对应的方法和坑点完全不同。今天我就把自己实测过的三种主流方法——Cookie提取法、网络请求拦截法和本地存储读取法——做一个全面的对比和复盘并附上我踩过的那些坑和对应的避坑指南。无论你是想实现自动签到、批量导出数据还是构建更复杂的自动化工作流这篇文章都能给你提供一份可直接“抄作业”的实操方案。2. 三种核心方法深度解析与对比获取Token的本质是模拟或复现用户登录后的身份认证状态。在Web应用中Token或Session通常存储在客户端的Cookie、LocalStorage/SessionStorage中或者作为请求头如Authorization的一部分。我们的目标就是通过自动化手段稳定、可靠地拿到这个凭证。下面这三种方法分别对应了不同的技术思路和适用场景。2.1 方法一Cookie提取法最直观但依赖浏览器状态这是大多数人首先想到的方法用Selenium打开浏览器模拟用户输入账号密码登录登录成功后直接从浏览器的Cookie中提取包含Token信息的那个字段。2.1.1 核心原理与操作步骤Selenium WebDriver提供了完整的API来操作浏览器。登录成功后所有服务器返回的Cookie都会被浏览器存储。我们可以通过driver.get_cookies()方法获取当前页面域名下的所有Cookie列表然后从中筛选出我们需要的那个。一个典型的操作流程如下初始化WebDriver启动一个浏览器实例如Chrome。访问登录页面导航到接龙管家的登录页。定位并填写表单找到用户名/密码的输入框填入凭据。这里通常需要处理可能的验证码后文会详细讲。点击登录按钮触发登录请求。等待登录成功使用显式等待WebDriverWait判断某个登录成功后的页面元素出现如用户头像或特定菜单。提取Cookie调用get_cookies()遍历列表找到name为token或类似auth_token、session的Cookie项其value就是我们需要的Token。from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC import time driver webdriver.Chrome() driver.get(https://你的接龙管家登录页地址) # 假设登录表单 username driver.find_element(By.NAME, username) password driver.find_element(By.NAME, password) username.send_keys(你的账号) password.send_keys(你的密码) # 处理可能的验证码此处为简单示例实际可能需OCR或手动介入 # captcha_input driver.find_element(By.ID, captcha) # captcha_value input(请输入验证码: ) # captcha_input.send_keys(captcha_value) login_button driver.find_element(By.XPATH, //button[typesubmit]) login_button.click() # 等待登录成功例如等待用户昵称元素出现 try: WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CLASS_NAME, user-avatar)) ) print(登录成功) except TimeoutException: print(登录超时或失败。) # 提取Cookie cookies driver.get_cookies() target_token None for cookie in cookies: if cookie[name] token: # 关键这里的name需要根据实际情况确定 target_token cookie[value] break if target_token: print(f获取到的Token: {target_token}) # 可以将token保存到文件或变量中供后续使用 else: print(未在Cookie中找到Token。) driver.quit()2.1.2 优势与适用场景优势逻辑最直观最接近真实用户行为。对于登录流程复杂如有多步验证、动态加载的网站这种方法最稳妥因为它完整地执行了所有前端JavaScript和页面跳转逻辑。适用场景适合登录流程稳定、验证码可处理或没有、且Token明确存储在Cookie中的情况。也适合需要维持完整浏览器会话进行后续复杂操作的场景。2.1.3 潜在风险与避坑指南坑点一Cookie名称不固定。Token对应的Cookiename可能不是简单的token可能是auth_token、sessionid、jwt等甚至带有前缀。解决方法在成功登录后先打印出所有的cookies列表仔细查看其name和value结构找到正确的那个。也可以使用浏览器开发者工具的Application-Storage-Cookies面板在手动登录后查看确认。坑点二登录状态判断失误。如果等待登录成功的条件设置不当例如等待一个不稳定的元素可能导致脚本在未登录成功时就尝试提取Cookie从而失败。解决方法使用更稳定、唯一的元素作为等待条件例如页面标题变化、URL跳转或者一个登录后必定存在的特定功能按钮的文本内容。坑点三验证码拦截。这是自动化登录最大的障碍。解决方法识别验证码类型如果是简单的图形验证码可以尝试集成OCR库如pytesseractPillow进行识别但识别率受图片复杂度影响。手动介入在开发调试阶段可以设置暂停(time.sleep(30))留出时间手动输入验证码。寻求替代方案如果网站提供短信或邮箱验证码登录且该流程更稳定可优先考虑。商业打码平台对于高频率需求可以考虑接入付费打码API。终极方案探讨是否有可能通过技术手段绕过或禁用验证码通常涉及安全策略需谨慎评估。坑点四浏览器环境检测。一些网站会检测浏览器是否由Selenium等自动化工具驱动。解决方法可以使用undetected-chromedriver这类库来隐藏自动化特征或者手动添加一些chrome_options来排除Chrome被控制的标志。from selenium.webdriver.chrome.options import Options chrome_options Options() chrome_options.add_argument(--disable-blink-featuresAutomationControlled) chrome_options.add_experimental_option(excludeSwitches, [enable-automation]) chrome_options.add_experimental_option(useAutomationExtension, False) driver webdriver.Chrome(optionschrome_options) # 同时执行一段JS来覆盖navigator.webdriver属性 driver.execute_script(Object.defineProperty(navigator, webdriver, {get: () undefined}))2.2 方法二网络请求拦截法更底层需分析流量如果Cookie提取法因为环境检测或验证码过于复杂而受阻或者我们想更“干净”地获取Token那么直接分析登录过程中的网络请求然后用Python的requests库复现这个请求是更高效、更隐蔽的方法。2.2.1 核心原理与操作步骤此方法完全脱离浏览器UI其核心是成为一个“协议级”的客户端。抓包分析使用浏览器开发者工具的Network面板快捷键F12在手动登录过程中记录下登录按钮点击后发出的那个POST请求。分析请求详情重点关注Request URL登录接口的地址。Request Method通常是POST。Request Headers尤其是Content-Type、User-Agent有时还会有X-CSRF-Token等自定义头。Request Payload/Form Data提交的数据包括用户名、密码、可能存在的隐藏字段如csrf_token、时间戳等。Response登录成功后的响应体。Token很可能直接出现在响应体的JSON数据中而不是仅存在于Cookie。用Python复现请求使用requests库构造相同的URL、请求头和请求体发送POST请求。从响应中提取Token解析响应通常是JSON找到Token字段。import requests import json # 登录接口URL (需要从抓包中获取) login_url https://api.jielongguanjia.com/api/v1/auth/login # 示例实际地址可能不同 # 构造请求头 (需要从抓包中复制User-Agent很重要) headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Content-Type: application/json, # 也可能是 application/x-www-form-urlencoded # 可能需要的其他头如 Referer, Origin } # 构造请求体 (需要从抓包中分析字段) payload { username: 你的账号, password: 你的密码, # 可能存在的其他字段如 # captcha: 验证码, # 如果接口需要验证码 # remember: True, # _csrf: 从登录页HTML或上一个GET请求的Cookie中提取 } # 发送登录请求 response requests.post(login_url, headersheaders, jsonpayload) # 如果Content-Type是json # 如果Content-Type是form-data则使用requests.post(login_url, headersheaders, datapayload) # 检查响应 if response.status_code 200: resp_data response.json() # 假设响应结构为 {code: 0, message: success, data: {token: eyJhbGciOiJ...}} if resp_data.get(code) 0: # 根据实际接口定义判断成功 token resp_data[data][token] print(f获取到的Token: {token}) # 通常还需要将token保存用于后续API请求 # 后续请求的headers里需要加入: headers[Authorization] fBearer {token} else: print(f登录失败: {resp_data.get(message)}) else: print(f请求失败状态码: {response.status_code})2.2.2 优势与适用场景优势执行速度快不依赖图形界面和浏览器资源占用低。更适合服务器环境或高频次执行。直接处理协议避开了前端UI变化带来的不稳定性。适用场景登录接口清晰、稳定且Token在响应体中返回的情况。非常适合集成到后端服务或脚本中。2.2.3 潜在风险与避坑指南坑点一动态参数如CSRF Token。很多现代Web应用为了安全会在登录表单中嵌入一个一次性的CSRF Token该Token在每次加载登录页时随机生成并需要随用户名密码一起提交。解决方法需要先发起一个GET请求到登录页从返回的HTML中解析出CSRF Token通常藏在meta标签或某个input hidden字段里然后再将其填入登录POST请求的载荷中。# 第一步获取登录页提取csrf_token session requests.Session() # 使用Session保持Cookie login_page_url https://jielongguanjia.com/login page_resp session.get(login_page_url) # 假设csrf_token在 meta namecsrf-token content... 中 # 这里用正则简单示例实际应用建议用BeautifulSoup import re csrf_token_match re.search(rmeta namecsrf-token content([^]), page_resp.text) if csrf_token_match: csrf_token csrf_token_match.group(1) payload[_csrf] csrf_token # 将token加入请求体坑点二请求签名或加密。更复杂的情况是登录接口对请求参数进行了签名或加密以防止简单的重放攻击。这通常会在前端JavaScript中进行处理。解决方法这大大增加了难度。你需要分析前端JS代码找到加密或签名的算法并用Python实现它。这可能涉及逆向工程技术门槛较高。一个折中的办法是使用Selenium配合requests让Selenium执行登录但中途通过监听网络请求利用driver.execute_script注入代码监听或使用selenium-wire等库来捕获最终发送出的、已经处理好的请求数据。坑点三User-Agent和请求头校验。服务器可能会校验User-Agent或其他请求头的完整性。解决方法确保你的requests请求头与真实浏览器发出的尽可能一致可以从浏览器开发者工具中直接复制。坑点四响应中的Token位置不明确。Token可能不在响应体的根层级而是嵌套在多层结构中或者字段名不是简单的token。解决方法仔细分析登录成功后的响应JSON结构。也可以先打印出完整的resp_data来查看。2.3 方法三本地存储读取法针对SPA应用对于单页面应用SPA如使用Vue.js、React等框架开发的Web应用Token很可能被存储在浏览器的LocalStorage或SessionStorage中而不是Cookie。接龙管家作为现代Web应用有很大概率采用这种方式。2.3.1 核心原理与操作步骤Selenium可以执行JavaScript来访问和操作浏览器的Window对象下的localStorage和sessionStorage。使用Selenium完成登录同方法一的前五步确保登录成功。通过JavaScript读取存储使用driver.execute_script()方法执行JS代码读取存储项。解析存储内容存储的内容可能是一个JSON字符串需要解析后才能得到Token。# 接方法一的登录成功后的代码... # 假设登录已完成driver处于登录后的页面 # 读取LocalStorage local_storage_token driver.execute_script(return window.localStorage.getItem(auth_token);) # auth_token是键名需根据实际情况修改 # 读取SessionStorage session_storage_token driver.execute_script(return window.sessionStorage.getItem(user_token);) print(fLocalStorage Token: {local_storage_token}) print(fSessionStorage Token: {session_storage_token}) # 如果存储的是JSON字符串例如存储了整个用户对象 user_info_str driver.execute_script(return window.localStorage.getItem(user_info);) if user_info_str: import json user_info json.loads(user_info_str) token_from_json user_info.get(token) print(f从LocalStorage JSON中解析的Token: {token_from_json})2.3.2 优势与适用场景优势对于将认证状态存储在Web Storage的SPA应用这是最直接、最准确的获取方式。比从Cookie中找更精准因为Web Storage的设计初衷就是用于在客户端存储较大量的数据。适用场景明确使用LocalStorage/SessionStorage管理Token的现代Web应用。通常在登录后应用会将用户信息和Token存入Storage。2.3.3 潜在风险与避坑指南坑点一存储键名未知。不知道应用具体用了哪个键Key来存储Token。解决方法在手动登录成功后打开浏览器开发者工具的Application-Storage-Local Storage/Session Storage查看当前域名下的存储项找到包含Token信息的键值对。坑点二存储内容加密或编码。Token可能被Base64编码或进行了其他简单处理后才存储。解决方法读取到字符串后先尝试json.loads()解析如果失败观察字符串特征如末尾常有尝试base64.b64decode()。也可以对比手动在浏览器中看到的值和脚本读取到的值是否一致。坑点三跨域限制。localStorage和sessionStorage受同源策略限制。解决方法确保你的Selenium脚本操作的页面与Token存储的页面是同源的域名、协议、端口一致。通常登录后停留在同一域名下就没有问题。坑点四Storage清理时机。sessionStorage在页面会话结束时关闭浏览器标签页会被清除而localStorage是持久化的。如果你的自动化流程需要在新标签页或新浏览器实例中使用Token使用localStorage中的Token可能更方便但需要注意安全性。解决方法根据你的自动化流程设计选择是从sessionStorage还是localStorage读取或者两者都尝试。3. 方法对比与选型决策指南为了更直观地对比这三种方法我将它们的关键特性总结如下表特性维度Cookie提取法网络请求拦截法本地存储读取法技术门槛较低主要使用Selenium基础API较高需抓包分析、处理动态参数、可能逆向JS中等需了解Web Storage和JS执行执行速度慢需启动浏览器、加载页面、执行UI操作极快纯HTTP请求慢同Cookie法依赖浏览器登录资源占用高占用完整浏览器进程极低仅网络库高同Cookie法稳定性较高模拟真实用户但受UI变化、验证码影响高直接对接接口但受接口变更、加密影响较高依赖浏览器但存储接口稳定隐蔽性低可能被识别为自动化工具高与普通HTTP客户端无异低同Cookie法主要适用场景登录流程复杂、强依赖前端交互、Token在Cookie中接口清晰、追求效率、Token在响应体中、服务器环境SPA应用、Token明确存储在Web Storage中主要挑战验证码、浏览器检测、Cookie名不确定CSRF Token、请求签名/加密、响应结构解析存储键名不确定、内容编码、跨页面使用如何选择我的建议是首选网络请求拦截法只要登录接口没有复杂的动态加密这是最优雅、最高效的方案。优先尝试抓包分析。次选本地存储读取法如果网站是明显的SPA且网络请求法因加密等原因受阻但UI自动化可行则用Selenium登录后从Storage读取。最后考虑Cookie提取法当前两种方法都走不通时例如登录过程有无法绕过的图形交互验证再使用这种最“笨”但最模拟真实的方法。同时如果后续操作需要维持一个活跃的浏览器会话而不仅仅是获取Token也必须使用此法。4. 实战进阶Token的后续使用与维护获取Token不是终点而是起点。拿到Token后我们通常要用来调用其他需要认证的API。4.1 Token的使用方式Bearer Token最常见的方式。在后续请求的Authorization头中加入Bearer {你的Token}。api_headers { Authorization: fBearer {token}, Content-Type: application/json } response requests.get(https://api.jielongguanjia.com/api/v1/user/profile, headersapi_headers)Cookie如果Token本身就是作为Cookie下发的方法一获取的那么使用requests.Session()对象会自动管理Cookie只需在登录后使用同一个session对象即可。# 假设使用requests复现了登录并获得了session内含cookie # session.post(login_url, data...) profile_response session.get(https://api.jielongguanjia.com/api/v1/user/profile)4.2 Token的维护与刷新Token通常有有效期。你需要处理Token过期的情况。捕获过期响应在调用API时检查响应状态码是否为401 Unauthorized或响应体中含有token expired等信息。实现刷新逻辑如果接口提供了刷新Token的接口通常用refresh_token换取新的access_token则在过期时自动调用刷新接口。持久化存储将Token及Refresh Token安全地存储到文件、数据库或环境变量中避免每次运行脚本都重新登录。封装请求函数最好将带Token的请求封装成一个函数在这个函数内统一处理Token过期和刷新的逻辑对上层调用透明。import json import time class JielongClient: def __init__(self, token_filetoken.json): self.token_file token_file self.access_token None self.refresh_token None self.token_expiry None self.session requests.Session() self.load_token() def load_token(self): try: with open(self.token_file, r) as f: data json.load(f) self.access_token data.get(access_token) self.refresh_token data.get(refresh_token) self.token_expiry data.get(expiry) # 简单检查是否过期这里假设expiry是时间戳 if self.token_expiry and time.time() self.token_expiry: print(Token已过期需要刷新或重新登录。) self.access_token None except FileNotFoundError: pass def save_token(self, access_token, refresh_token, expires_in3600): self.access_token access_token self.refresh_token refresh_token self.token_expiry time.time() expires_in - 60 # 提前60秒过期 data { access_token: access_token, refresh_token: refresh_token, expiry: self.token_expiry } with open(self.token_file, w) as f: json.dump(data, f) def refresh_access_token(self): 调用刷新接口获取新token if not self.refresh_token: return False refresh_url https://api.jielongguanjia.com/api/v1/auth/refresh payload {refresh_token: self.refresh_token} resp self.session.post(refresh_url, jsonpayload) if resp.status_code 200: new_data resp.json() self.save_token(new_data[access_token], new_data.get(refresh_token, self.refresh_token), new_data.get(expires_in, 3600)) return True return False def make_authenticated_request(self, method, url, **kwargs): 封装请求自动处理token过期 if not self.access_token: # 如果没有token需要先登录这里省略登录逻辑 pass headers kwargs.get(headers, {}) headers[Authorization] fBearer {self.access_token} kwargs[headers] headers response self.session.request(method, url, **kwargs) # 检查是否因token过期失败 if response.status_code 401: print(Token可能过期尝试刷新...) if self.refresh_access_token(): # 刷新成功用新token重试请求 headers[Authorization] fBearer {self.access_token} kwargs[headers] headers response self.session.request(method, url, **kwargs) else: print(刷新Token失败需要重新登录。) # 触发重新登录逻辑 return response # 使用示例 client JielongClient() # 首次需要登录假设login方法会调用save_token # client.login(username, password) resp client.make_authenticated_request(GET, https://api.jielongguanjia.com/api/v1/some/protected/resource)5. 常见问题排查与安全建议5.1 问题排查清单登录失败检查账号密码是否正确。检查网络请求的URL、请求头、载荷是否与抓包结果完全一致特别是隐藏字段。检查是否有验证码未处理。检查服务器返回的错误信息状态码和响应体。找不到TokenCookie法打印所有Cookie确认名称和值。检查登录是否真的成功页面是否跳转。网络请求法打印完整的登录响应JSON仔细查找Token字段。确认登录请求是否成功状态码200且业务码成功。存储法在浏览器开发者工具中确认Storage里确实存有Token并核对键名。确保执行JS读取的时机在登录完成之后。Token无效调用API返回401Token已过期需要刷新或重新登录。Token使用方式错误例如Bearer Token未加Bearer前缀或放在了错误的请求头中。Token对应的权限不足无法访问目标API。5.2 安全与合规建议自动化操作需谨慎务必遵守目标网站的服务条款。尊重robots.txt检查目标网站是否允许爬虫或自动化访问。控制请求频率在脚本中添加延时如time.sleep(random.uniform(1, 3))避免对服务器造成压力防止IP被封。妥善保管凭证不要将账号密码、Token硬编码在脚本中。使用环境变量或配置文件并确保配置文件不被提交到公开的代码仓库。用于合法目的确保你的自动化脚本用于个人学习、效率提升或已获得授权的场景不得用于恶意攻击、数据盗取或干扰服务正常运行。考虑使用官方API如果接龙管家提供官方API应优先使用。官方API通常更稳定、更安全且符合平台规则。本文讨论的方法主要适用于没有开放API或API功能受限的情况。获取Token只是自动化之旅的第一步但也是最关键的一步。希望这三种方法的详细对比和避坑指南能帮你找到最适合自己项目场景的路径。在实际操作中往往需要结合多种方法并根据网站的具体实现进行灵活调整。多观察、多分析、多测试是解决这类问题的唯一法门。