1. 项目概述与核心痛点做UI自动化测试的朋友估计都绕不开登录这个坎儿。尤其是现在稍微有点安全意识的系统登录页面上个验证码几乎是标配。你脚本写得再溜到了验证码这里也得“卡壳”——总不能指望脚本自己看懂图片里的扭曲数字或者点选一堆火锅食材吧。我最近在折腾一个内部运营系统的自动化巡检就遇到了这个经典难题系统登录强制要求图形验证码每天需要定时跑好几轮数据抓取和功能检查。如果每次执行都卡在手动输入验证码这一步那所谓的“自动化”就名存实亡了。这个项目的核心思路其实就藏在标题里首次手动后续免登。说白了就是利用Web会话的核心——Cookie。我们第一次通过脚本辅助或者完全手动完成包含验证码的登录然后把这个成功登录后的Cookie“宝藏”保存下来。之后在Cookie的有效期内我们的自动化脚本就可以直接携带这个Cookie去访问系统系统会认为这是同一个已登录的会话从而绕过登录页面直达目标功能页面。这就像你去一家会员制商店第一次需要前台登记手动登录之后每次亮出会员卡Cookie就可以直接进去了。这个方法特别适合那些验证码仅在登录时出现登录后各功能页面不再二次验证的系统。它完美避开了验证码识别这个技术深坑把复杂度从“让机器学会认字”降维到“让机器学会保存和复用凭证”实现成本和稳定性都高出一大截。接下来我就把这次实战中从思路设计到代码实现再到各种坑的解决方案完整地梳理一遍。2. 核心原理Cookie与会话保持机制要玩转这个方案必须得先搞清楚Cookie在Web登录里扮演的角色。不然你很可能在保存了一堆“无效饼干”之后还在纳闷为什么系统不认。2.1 Cookie是什么为什么能用来免登录你可以把HTTP协议想象成一个有严重健忘症的服务员。你每次去餐厅发送请求他都会把你当成完全陌生的新客人。为了解决“记住客人”这个问题餐厅经理服务器想了个办法在你第一次成功消费登录后给你一张特制的“会员卡”Cookie。这张卡上写着一串只有餐厅系统能看懂的加密信息比如你的会员ID、登录时间、会话有效期等。之后你每次来只要出示这张卡浏览器在请求中自动携带Cookie服务员就能认出你直接为你提供会员服务访问需登录的页面而不用你再每次报手机号验证码重新登录。在技术层面Cookie就是服务器通过Set-Cookie响应头发送给浏览器的一小段文本数据。浏览器会按照规则域名、路径、有效期等存储它并在后续向同一服务器发起请求时自动通过Cookie请求头将其回传。我们自动化脚本要做的就是模拟浏览器的这个行为获取并保存登录成功的Cookie然后在后续请求中手动携带它。2.2 手动登录与Cookie获取的时机这里有一个非常关键的细节登录成功后的Cookie并不是在输入用户名密码点击“登录”按钮的那个请求里直接拿到的。一个典型的包含验证码的登录流程往往是这样的访问登录页获取页面上的验证码图片通常是一个单独的接口请求返回图片二进制流或Base64。人工识别或通过其他方式获取验证码内容。向登录接口如/api/login发起一个POST请求提交用户名、密码、验证码等信息。登录接口验证通过后会在响应头里通过Set-Cookie字段下发新的、标识已登录会话的Cookie常见的有SESSION,JSESSIONID,token等名称。浏览器接收到这个响应就会保存这些Cookie。所以我们手动登录的目标核心是触发第4步并捕获到服务器下发的那个“会员卡”Cookie。在自动化脚本中我们可以在人工介入输入验证码后让脚本继续执行捕捉登录请求的响应头将其中的Cookie值提取并持久化保存。2.3 Cookie的有效期与更新策略Cookie不是永久有效的。服务器在设置Cookie时通常会指定一个Max-Age或Expires属性来定义它的生命周期。常见的有会话Cookie不设置过期时间浏览器关闭即失效。对于自动化脚本这类Cookie意义不大因为我们的脚本进程重启后就没了。持久Cookie设置了明确的过期时间可能几小时、几天甚至几周。这是我们方案能成立的基石。因此在项目设计时我们必须考虑Cookie的刷新机制读取Cookie时检查过期时间如果发现已过期则重新走手动登录流程。设计主动刷新机制在Cookie临近过期例如剩余有效期不足10%时在脚本中主动调用一个“保活”接口或者直接重新登录获取新Cookie。异常处理任何时候携带Cookie的请求如果被系统返回401/403未授权或跳转回登录页都应该触发Cookie失效的逻辑并通知需要重新登录。3. 技术选型与工具准备工欲善其事必先利其器。实现这个方案我们需要选择合适的UI自动化工具和辅助库。3.1 UI自动化框架选择Selenium vs. Playwright目前主流的Web UI自动化框架主要是Selenium和微软推出的Playwright。两者都能满足我们的需求但有些细微差别。Selenium老牌王者生态成熟社区资源丰富。通过WebDriver与浏览器交互。对于这个项目它的优点是稳定缺点是默认不提供便捷的请求/响应拦截功能获取登录接口的响应Cookie需要额外配置如使用Chrome DevTools Protocol或BrowserMob Proxy。Playwright后起之秀由微软开发原生支持多浏览器Chromium, Firefox, WebKit。它的一个巨大优势是强大的网络请求控制能力。我们可以非常轻松地监听page.on(‘request’)和等待page.waitForResponse()特定请求并直接获取其响应头和Cookie。这让我们捕获登录接口的Cookie变得异常简单。考虑到我们项目的核心难点在于精准捕获登录成功瞬间的CookiePlaywright的网络API提供了更优雅的解决方案。因此本次实践我选择了Playwright for Python。工具清单编程语言Python 3.8UI自动化框架Playwright浏览器Playwright 自带的 Chromium无需单独安装ChromeCookie存储JSON文件简单易用配置管理Python的configparser或直接使用字典定时任务根据部署环境可选系统Cron、Jenkins、Airflow等。3.2 项目目录结构设计一个清晰的结构有助于后期维护。我的项目目录大致如下captcha_login_by_cookie/ ├── configs/ # 配置文件 │ └── system_config.ini # 系统URL、账号等配置 ├── cookies/ # 存储Cookie的目录 │ └── system_a_cookies.json ├── logs/ # 日志目录 ├── src/ │ ├── core/ │ │ ├── __init__.py │ │ ├── cookie_manager.py # Cookie管理核心类保存、加载、验证 │ │ └── login_operator.py # 登录操作核心类手动登录、捕获Cookie │ ├── tasks/ # 具体的自动化业务任务 │ │ └── data_collector.py │ └── main.py # 主程序入口 ├── requirements.txt # Python依赖列表 └── README.md4. 核心实现步骤详解让我们进入最关键的实操环节。整个过程可以分为三大步首次手动登录并保存Cookie、后续运行加载Cookie免登、以及Cookie的维护与更新。4.1 第一步实现首次手动登录与Cookie捕获这是整个流程的起点也是最需要人工干预的一步。我们的目标是打开浏览器导航到登录页在脚本暂停时人工输入验证码脚本在登录成功后自动截获并保存Cookie。4.1.1 初始化浏览器与页面监听首先我们需要用Playwright启动一个浏览器上下文Context并开启一个页面Page。关键点在于我们要在登录请求发起前就设置好对网络响应的监听。# login_operator.py import asyncio from playwright.async_api import async_playwright import json import os class LoginOperator: def __init__(self, config): self.login_url config[login_url] self.cookie_file_path config[cookie_file_path] self.username config[username] self.password config[password] # 用于存储捕获到的登录响应Cookie self.captured_cookies None async def manual_login_and_save_cookie(self): 执行手动登录并保存Cookie async with async_playwright() as p: # 启动浏览器headlessFalse表示显示界面方便人工操作 browser await p.chromium.launch(headlessFalse, slow_mo100) # slow_mo让动作变慢便于观察 context await browser.new_context() page await context.new_page() # **关键步骤监听网络响应** # 定义一个回调函数当收到响应时触发 async def on_response(response): # 判断是否是登录接口的响应根据实际URL调整 if /api/login in response.url or login.do in response.url: print(f捕获到登录响应: {response.url}) if response.status 200: # 尝试从响应头获取Cookie headers response.headers set_cookie_header headers.get(set-cookie) if set_cookie_header: print(f找到Set-Cookie头: {set_cookie_header[:50]}...) # Playwright更推荐的方式直接从响应对象获取所有Cookie try: # 获取本次响应设置的Cookie这是一个列表 cookies await response.cookies() if cookies: self.captured_cookies cookies print(f成功从响应中解析出 {len(cookies)} 个Cookie) except Exception as e: print(f从响应解析Cookie失败: {e}) # 添加监听器 page.on(response, on_response) # 导航到登录页面 print(f正在打开登录页面: {self.login_url}) await page.goto(self.login_url) await page.wait_for_load_state(networkidle) # 等待页面基本加载完成 # 自动填写用户名和密码验证码需要人工输入 await page.fill(input[nameusername], self.username) await page.fill(input[namepassword], self.password) print(用户名和密码已自动填充。) # **关键此处脚本暂停等待人工输入验证码** # 我们让脚本等待一个页面上不存在的元素或者直接sleep给人留出操作时间。 # 更友好的方式是在验证码输入框填充后给用户一个明确的提示。 verification_code_input page.locator(input[namecaptcha]) await verification_code_input.wait_for(statevisible) print(*50) print(【请人工操作】浏览器窗口已弹出。) print(f请查看页面上的验证码并将其输入到对应的输入框中。) print(输入完成后请回到此控制台并按 Enter 键继续...) print(*50) input(人工输入验证码完成后按 Enter 键继续执行脚本...) # 人工输入完成后脚本继续点击登录按钮 await page.click(button[typesubmit]) # 根据实际登录按钮选择器调整 # 等待登录请求完成并给监听器一点时间处理响应 await page.wait_for_timeout(3000) # 等待3秒确保响应被捕获 # 检查是否成功捕获到Cookie if self.captured_cookies: print(登录成功捕获到Cookie。) # 保存Cookie到文件 await self._save_cookies_to_file(self.captured_cookies, context) print(fCookie已保存至: {self.cookie_file_path}) else: print(警告未捕获到登录响应Cookie。可能是登录失败或登录接口URL不匹配。) # 这里可以加入截图等调试手段 await page.screenshot(pathlogin_failed.png) raise Exception(登录失败或未捕获到Cookie) await browser.close() async def _save_cookies_to_file(self, cookies, context): 将Cookie保存为JSON文件 # 我们不仅保存从响应里捕获的Cookie也保存当前浏览器上下文的所有Cookie更完整。 all_cookies await context.cookies() # 将Cookie对象字典列表转换为可序列化的格式 cookies_to_save [] for cookie in all_cookies: # 只保存必要的字段 cookies_to_save.append({ name: cookie[name], value: cookie[value], domain: cookie[domain], path: cookie[path], expires: cookie.get(expires, -1), # expires可能是float httpOnly: cookie.get(httpOnly, False), secure: cookie.get(secure, False), sameSite: cookie.get(sameSite, Lax) }) # 确保目录存在 os.makedirs(os.path.dirname(self.cookie_file_path), exist_okTrue) with open(self.cookie_file_path, w, encodingutf-8) as f: json.dump(cookies_to_save, f, indent2, ensure_asciiFalse)注意上面的代码使用了input()来阻塞控制台等待人工操作。这在本地运行没问题但如果部署到无界面的服务器headless环境这种方法就失效了。对于服务器环境首次登录可能需要通过其他方式解决例如在本地完成首次登录并保存Cookie文件然后将Cookie文件上传到服务器。使用更复杂的交互方式如通过消息队列接收人工输入的验证码。如果验证码非常简单且固定可以考虑极低概率的OCR尝试不推荐不稳定。4.1.2 Cookie文件解析保存下来的Cookie文件是一个JSON数组每个元素是一个Cookie字典。理解其结构对后续加载很重要。[ { name: SESSION, value: NzI1YjM0NDgtOGU1Mi00YTQwLTk4MzAtYjFjMWRiMzJkODU0, domain: .your-system.com, path: /, expires: 1740123456.789, httpOnly: true, secure: true, sameSite: Lax }, { name: USER_TOKEN, value: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..., domain: www.your-system.com, path: /, expires: -1, httpOnly: false, secure: false, sameSite: None } ]4.2 第二步加载Cookie实现免登录访问拿到“会员卡”后后续的自动化任务就轻松了。我们只需要在启动浏览器时把保存的Cookie“喂”给浏览器上下文即可。4.2.1 Cookie管理器的实现我们需要一个专门的类来负责Cookie的加载、验证和过期检查。# cookie_manager.py import json import time from pathlib import Path class CookieManager: def __init__(self, cookie_file_path): self.cookie_file_path Path(cookie_file_path) self.cookies [] def load_cookies(self): 从文件加载Cookie并检查基本有效性 if not self.cookie_file_path.exists(): print(fCookie文件不存在: {self.cookie_file_path}) return False try: with open(self.cookie_file_path, r, encodingutf-8) as f: self.cookies json.load(f) print(f成功从 {self.cookie_file_path} 加载了 {len(self.cookies)} 个Cookie。) return True except Exception as e: print(f加载Cookie文件失败: {e}) return False def is_cookie_valid(self): 检查Cookie是否有效未过期 if not self.cookies: return False current_time time.time() for cookie in self.cookies: expires cookie.get(expires) # expires为-1表示会话Cookie无法判断持久性我们假设有效。 # expires为0或不存在通常也表示会话Cookie。 if expires and expires 0: # 有明确的过期时间戳 if current_time expires: print(fCookie {cookie.get(name)} 已过期 (过期时间: {time.ctime(expires)})) return False else: # 可选检查是否临近过期例如剩余时间小于10% time_left expires - current_time original_ttl ... # 需要知道原始TTL这里简化处理 # if time_left / original_ttl 0.1: # print(fCookie {cookie.get(name)} 即将过期) # return False # 或标记为需要刷新 pass return True def get_cookies_for_playwright(self): 将存储的Cookie格式转换为Playwright可用的格式 playwright_cookies [] for c in self.cookies: # Playwright的add_cookies方法需要的字段 pw_cookie { name: c[name], value: c[value], domain: c[domain], path: c[path], } # 处理过期时间Playwright期望的是Unix时间戳秒 expires c.get(expires) if expires and expires 0: pw_cookie[expires] expires # 其他可选字段 if c.get(httpOnly) is not None: pw_cookie[httpOnly] c[httpOnly] if c.get(secure) is not None: pw_cookie[secure] c[secure] if c.get(sameSite): pw_cookie[sameSite] c[sameSite] playwright_cookies.append(pw_cookie) return playwright_cookies4.2.2 业务任务脚本免登录访问现在我们可以编写具体的自动化任务了。这个任务脚本会先检查Cookie有效则直接使用无效则触发重新登录流程。# data_collector.py import asyncio from playwright.async_api import async_playwright from src.core.cookie_manager import CookieManager from src.core.login_operator import LoginOperator import sys class DataCollectorTask: def __init__(self, config): self.config config self.cookie_manager CookieManager(config[cookie_file_path]) self.login_operator LoginOperator(config) async def run(self): 执行数据收集任务 # 1. 检查Cookie是否有效 need_login False if self.cookie_manager.load_cookies(): if self.cookie_manager.is_cookie_valid(): print(Cookie有效尝试免登录访问。) else: print(Cookie已过期需要重新登录。) need_login True else: print(无有效Cookie文件需要首次登录。) need_login True # 2. 如果需要登录则执行手动登录流程 if need_login: print(开始手动登录流程...) await self.login_operator.manual_login_and_save_cookie() # 登录后重新加载Cookie if not self.cookie_manager.load_cookies(): print(错误登录后仍无法加载Cookie任务终止。) return print(登录成功Cookie已更新。) # 3. 使用有效的Cookie启动浏览器执行业务操作 async with async_playwright() as p: browser await p.chromium.launch(headlessTrue) # 后续任务可以无头运行 # **关键创建上下文时注入Cookie** context await browser.new_context() await context.add_cookies(self.cookie_manager.get_cookies_for_playwright()) page await context.new_page() # 尝试访问一个需要登录才能看的页面验证Cookie是否生效 dashboard_url self.config[dashboard_url] print(f正在访问仪表盘: {dashboard_url}) await page.goto(dashboard_url) # 检查是否成功绕过登录页 # 方法1检查当前URL是否还在登录页 current_url page.url if login in current_url: print(警告可能被重定向到了登录页Cookie可能无效。) # 可以截图并退出 await page.screenshot(pathaccess_denied.png) await browser.close() raise Exception(免登录访问失败请检查Cookie。) # 方法2检查页面中是否出现了登录后才有的元素 welcome_selector .welcome-user # 根据实际页面调整 try: await page.wait_for_selector(welcome_selector, timeout5000) print(成功免登录进入系统) except Exception as e: print(f未找到登录后元素可能访问失败: {e}) await page.screenshot(pathelement_not_found.png) # 不一定失败可能是选择器问题继续执行或根据业务逻辑判断 # 4. 在这里开始你的实际自动化业务逻辑... # 例如采集数据 print(开始执行数据采集任务...) # await page.click(.data-export-btn) # await page.wait_for_selector(.download-complete) # ... 其他操作 # 任务完成后可以清理或保持浏览器打开 await browser.close() print(数据采集任务完成。) # 主程序入口 async def main(): # 从配置文件读取配置 config { login_url: https://your-system.com/login, dashboard_url: https://your-system.com/dashboard, cookie_file_path: ./cookies/system_a_cookies.json, username: your_username, password: your_password } task DataCollectorTask(config) await task.run() if __name__ __main__: asyncio.run(main())4.3 第三步Cookie的维护、更新与异常处理Cookie不是一劳永逸的。我们需要一套机制来处理Cookie失效的情况。4.3.1 被动刷新异常检测与重登录在业务脚本中任何网络请求都可能因为Cookie失效而返回错误。我们需要一个全局的异常捕获和恢复机制。# 在 data_collector.py 的 run 方法中业务逻辑部分可以这样包裹 try: # 你的业务操作比如点击按钮、提取数据 data await page.text_content(.data-table) if not data: # 可能页面状态不对触发一次状态检查 raise Exception(未获取到预期数据) except Exception as e: print(f业务操作发生异常: {e}) # 检查是否是认证问题例如页面跳转到了登录页 current_url page.url if login in current_url: print(检测到被重定向至登录页Cookie已失效。) # 1. 清理无效的Cookie文件 import os if os.path.exists(self.config[cookie_file_path]): os.remove(self.config[cookie_file_path]) print(已删除无效Cookie文件。) # 2. 触发重新登录流程这里可以递归调用或设置一个重试标志 print(尝试重新登录...) # 注意在无头模式下重新登录需要特殊处理如抛出错误由外部调度器处理 # 这里我们简单抛出一个特定异常让主程序知道需要重新登录 raise NeedReLoginException(Cookie失效需要重新进行手动登录。) else: # 其他类型的异常直接向上抛出 raise4.3.2 主动刷新定期保活对于生命周期较长的Cookie我们可以设计一个“保活”任务定期访问系统的一个轻量级接口如/api/heartbeat或用户信息接口以刷新会话的活跃时间防止因长时间无操作导致的会话过期。async def keep_session_alive(self, page): 保活函数定期调用以维持会话 try: # 访问一个不需要渲染页面、简单的API接口 # 使用 page.request 直接发送API请求效率更高 response await page.request.get(https://your-system.com/api/user/profile) if response.status 200: print(会话保活成功。) # 可以检查返回内容确认用户身份 # profile await response.json() # if profile.get(username) self.config[username]: # print(用户身份确认。) return True else: print(f保活请求失败状态码: {response.status}) return False except Exception as e: print(f保活请求异常: {e}) return False # 在长时间运行的任务中可以定时调用 # asyncio.create_task(periodic_keep_alive())5. 常见问题、踩坑记录与优化建议在实际操作中我遇到了不少坑。这里总结一下希望能帮你绕过去。5.1 Cookie捕获不到或捕获不全问题按照教程写了监听但self.captured_cookies始终是空的。排查登录接口URL不匹配if /api/login in response.url这行代码里的路径可能不对。打开浏览器的开发者工具F12切换到Network网络标签页清空记录然后手动完成一次登录。找到那个真正的登录请求通常是POST查看它的Request URL用这个来修正你的判断条件。Cookie设置在初始页面有些系统可能在加载登录页时就已经设置了一个初步的会话Cookie比如用于跟踪验证码的session。登录成功只是更新了这个Cookie的值。这时你应该监听所有响应或者改为在点击登录按钮后从最终的浏览器上下文中获取所有Cookieawait context.cookies()这通常更可靠。我上面的代码已经采用了这种更稳妥的方式。跨域问题如果登录接口的域名和页面域名不同跨域Cookie的domain和sameSite属性会影响其存储和发送。确保你保存的Cookie的domain属性包含了你要访问的业务页面的域名。5.2 加载Cookie后访问仍然跳转登录页问题成功加载了Cookie文件但访问系统内部页面时还是被重定向到了/login。排查Cookie作用域Domain/Path不匹配检查保存的Cookie的domain和path属性。domain必须是你要访问的页面的父域或同级域例如Cookie的domain是.example.com可以用于www.example.com和api.example.com。path属性决定了Cookie在哪些路径下会被发送。如果业务页面路径不在Cookie的path范围内浏览器不会发送该Cookie。缺少关键Cookie登录状态可能由多个Cookie共同标识例如一个SESSIONID和一个USER_TOKEN。你可能只捕获了其中一个。确保保存的是context.cookies()返回的全部Cookie。Secure/HttpOnly标志如果Cookie被标记为Secure它只能通过HTTPS连接传输。如果你的测试环境是HTTP这个Cookie不会被发送。同样HttpOnly的Cookie无法通过JavaScript如document.cookie读取但Playwright在浏览器上下文层面注入是没问题的。浏览器上下文隔离Playwright的每个browser.new_context()都是一个独立的会话上下文其Cookie是隔离的。你必须确保在同一个上下文中先add_cookies然后用这个上下文创建页面new_page。跨上下文Cookie不共享。5.3 无头Headless模式下的首次登录难题问题脚本部署到服务器后没有图形界面input()等待人工输入验证码的步骤完全失效。解决方案本地生成上传服务器这是最推荐的方式。在本地开发机有图形界面上运行一次manual_login_and_save_cookie()函数生成cookies.json文件。然后将这个文件连同代码一起部署到服务器。只要Cookie在有效期内服务器上的脚本就可以直接使用。分离登录与任务将登录脚本和业务脚本拆成两个独立的任务。登录脚本是一个需要人工触发的“维护任务”只在Cookie失效时由管理员在本地或通过远程桌面如果有到服务器上执行一次。业务脚本是定时任务只负责加载Cookie和执行操作。使用可破解的简单验证码仅限测试环境如果测试环境的验证码是固定的如“1234”或极其简单的数字可以尝试接入OCR服务如Tesseract但成功率无法保证且一旦验证码变化脚本就挂维护成本高。生产环境切勿依赖此方法。第三方打码平台成本与合规性考量对于必须全自动化的场景可以考虑付费的验证码识别平台。这需要将验证码图片上传到平台获取识别结果。这会引入网络延迟、额外成本和依赖并需要考虑账号安全和合规问题。5.4 Cookie过期时间处理不准确问题脚本判断Cookie未过期但使用时却失效了。原因服务器返回的expires时间是GMT格式的字符串如Fri, 31 Dec 2024 23:59:59 GMT或Unix时间戳秒。我们在保存时用json.dump如果直接存字符串没问题但如果将其转换成了Python的datetime对象再序列化就可能出问题。确保保存的是原始的数字时间戳或字符串。建议在_save_cookies_to_file方法中尽量保持从Playwright获取的原始expires值它是一个浮点数表示Unix时间戳。在is_cookie_valid中直接与time.time()返回浮点型时间戳进行比较。5.5 安全性警告Cookie是敏感信息它等同于你的账号密码。务必妥善保管cookies.json文件。不要将Cookie文件提交到版本控制系统如Git。在.gitignore中加入cookies/和*.json如果存Cookie。考虑对Cookie文件进行加密存储尤其是在共享环境中。遵守法律法规和系统规则此方法仅用于自己拥有权限的、或公司内部授权的、用于自动化测试/巡检的系统。严禁用于未经授权的网站爬取或攻击这不仅是违法行为也可能导致你的IP或账号被封禁。6. 方案扩展与高级玩法基础功能跑通后可以考虑一些增强功能让整个系统更健壮、更智能。6.1 多账号/多环境Cookie管理如果你的自动化任务需要操作多个测试账号或者需要同时对接测试环境和预发布环境可以扩展CookieManager使其支持根据username和base_url作为键来存储和加载不同的Cookie文件。配置文件可以设计成列表形式存储多套账号和环境信息。6.2 集成到CI/CD流水线将登录脚本作为Jenkins或GitLab CI的一个手动触发任务Manual Job。当Cookie失效时流水线任务会失败并通知负责人。负责人触发“更新Cookie”任务在带有图形界面的CI节点或通过VNC连接到的一个节点上完成手动登录更新共享存储如AWS S3、内部文件服务器中的Cookie文件。后续的自动化任务再从共享存储读取最新的Cookie。6.3 添加心跳检测与自动恢复在长时间运行的守护进程式自动化脚本中可以启动一个后台线程或异步任务定期如每30分钟调用keep_session_alive函数。如果保活失败则主动标记Cookie失效并尝试调用重新登录流程如果环境允许或者发送告警通知。6.4 使用更安全的凭证存储对于生产环境不建议将密码明文写在配置文件中。可以使用环境变量、密钥管理服务如AWS Secrets Manager, HashiCorp Vault或加密的配置文件来存储用户名和密码。登录脚本运行时从这些安全源获取凭证。这个“首次手动后续免登”的方案本质上是用一次性的手动成本换取长期稳定的自动化收益。它完美地绕过了UI自动化中最棘手的验证码问题将技术焦点从图像识别拉回到了更可控的HTTP会话管理上。在实际项目中它帮我节省了每天数小时的手动重复登录时间让自动化脚本真正实现了7x24小时无人值守运行。最关键的是它的稳定性和可维护性远超那些依赖脆弱OCR的方案。如果你也受困于验证码登录不妨试试这个思路。