1. 先把“多进程”这个词拆开你到底撞上的是哪一种我在做浏览器自动化采集和批量测试的时候反复被同一个问题绊住明明启动的是同一台机器上的 Microsoft EdgeA 窗口登录好了B 窗口打开还是未登录状态cookies 像是被谁偷偷擦掉了。一开始我以为是网站的问题后来才发现根源在浏览器的多进程架构和 profile用户数据目录的隔离机制上。这篇文章不谈虚的专门讲清楚三件事同一个 Edge 为什么会出现“多进程不共享 cookies”这些 cookies 到底存在哪儿、什么时候落盘以及在做 Python 多进程自动化时怎么用工程手段让登录态正确地在多个进程之间流转。适合正在写爬虫、做自动化测试、搞多账号批量操作的同学也适合单纯好奇“浏览器怎么这么占内存”的人。看懂之后你至少能少走两天的弯路。1.1 浏览器的多进程和你程序的多进程不是一回事很多人一说“多进程”就想到 Python 的multiprocessing但浏览器这边是完全独立的另一套体系。现代 Chromium 内核Edge 就是基于它采用的是多进程架构主要角色大概这么几类浏览器主进程负责窗口、菜单、生命周期调度渲染进程负责解析 HTML、执行 JS站点隔离开启后不同站点通常跑在不同渲染进程里GPU 进程负责合成与绘制网络服务负责实际的网络请求还有存储服务、工具进程等。关键点在于cookies 这种状态数据既不属于渲染进程也不属于你的 Python 进程它归属于“用户数据目录”这一层。所以当你在排查“为什么不共享”时第一件要做的事不是看代码而是问自己这几个进程读的是不是同一个用户数据目录绝大多数时候答案是否定的。1.2 三种“cookie 不共享”场景先对号入座我把实际遇到过的情况归成三类你可以直接对照。第一类是不同 user-data-dir 启动的多个实例。自动化脚本里为了并行习惯给每个任务扔一个独立目录比如D:\edge-profiles\p01、p02这时候每个目录就是一套完全独立的浏览器身份cookies、localStorage、缓存、扩展全是分开的绝对不共享这是设计如此不是 bug。第二类是同一 user-data-dir 但被多个进程同时打开。Chromium 有单实例保护机制会通过锁文件或命名管道检测到目录已被占用第二个进程通常会把启动参数转发给已有实例然后自己退出。如果你在自动化代码里看到“浏览器瞬间启动又消失”“driver 报连接失败”大概率就是这个原因而不是 cookies 的问题。第三类是IE 模式标签页和普通标签页混用。这个最阴因为看起来像同一个窗口实际上是两套存储。后面我会单独用一节讲。1.3 为什么有人坚持说“我明明用的是同一个浏览器”这个疑问我太理解了。因为在普通用户视角下双击桌面图标打开的每一个窗口都写着 Microsoft Edge看起来就是同一个浏览器。但工程视角下“同一个浏览器”这个说法是没有意义的真正决定身份的是启动时使用的 profile 目录。没有显式指定--user-data-dir时Edge 默认走%LOCALAPPDATA%\Microsoft\Edge\User Data里面的Default、Profile 1、Profile 2就是多个 profile。你在界面上切换“个人资料”本质上就是切换了 cookies 的账本。所以“同一个浏览器不共享 cookies”这句话更准确的表述是同一个安装、不同 profile、或者不同 user-data-dir 的实例之间不共享 cookies。2. Cookie 的落盘与内存机制共享为什么这么别扭理解了架构接下来要搞清楚数据在哪。这决定了你能用什么方式去“搬运”登录态。很多人卡在这里是因为他们以为 cookies 是一个可以随手复制的文件实际上它比想象中麻烦。2.1 真正管 cookie 的是用户数据目录在 Windows 上Edge 的 cookies 数据库通常位于用户数据目录下的 profile 文件夹里路径形态大致是...\User Data\Default\Network\Cookies。注意中间的Network这一层早期版本直接放在Default\Cookies后来随网络服务架构调整挪了位置所以你在网上搜到的老教程路径可能对不上。这个文件是一个 SQLite 数据库里面一张cookies表字段包括 host_key、name、encrypted_value、path、expires_utc、is_secure、is_httponly、samesite 等。也就是说cookie 的 Domain、Path、过期时间、HttpOnly、SameSite 这些属性全都在这个文件里有对应列不是浏览器随便记的。而同目录下的Local State文件里存放着用于解密 cookie 值的密钥材料。这一点非常关键它决定了你能不能靠“复制文件”来实现登录态迁移。2.2 Cookies 文件不是实时写的这是我踩过最深的坑之一。Chromium 出于性能考虑不会每收到一个Set-Cookie就往磁盘写一次而是先写在内存里的 cookie 存储中然后按批次、按时间间隔通常是几十秒级别、或者在内存压力大、浏览器正常关闭时才把变更刷进 SQLite 数据库。后果是什么你在浏览器还开着的时候去复制Cookies文件很可能拿到的是几分钟前的旧状态刚登录成功的那条会话 cookie 根本没在里面。然后你把这文件塞给另一个 profile结果发现还是未登录白折腾半天。注意需要搬运登录态时不要复制正在运行的 profile 里的 Cookies 文件走浏览器自身提供的导出接口才靠谱。2.3 从 Set-Cookie 响应头到磁盘的完整链路把链路捋一遍你对“为什么慢一拍”就彻底清楚了。服务器返回响应头部带一条或多条Set-Cookie例如Set-Cookie: sidabc123; Path/; HttpOnly; Secure; SameSiteLax; Max-Age86400。网络服务收到后解析这条指令交给 cookie 存储模块存储模块根据 Domain 和 Path 判断归属检查是否被现有规则覆盖然后写入内存中的 cookie 表如果设置了Max-Age或Expires它是持久 cookie会在后续某个刷盘时机落到 SQLite如果没设过期时间它是会话 cookie只在内存中存活浏览器进程完全退出就消失。所以你会看到一种现象同一个 profile 里关掉浏览器再打开登录态还在因为持久 cookie 落盘了而某些站点的“临时登录态”一关就没因为那是会话 cookie。这跟共享不共享无关是 cookie 自身属性决定的。2.4 加密这件事直接堵死了“复制文件大法”即便你等浏览器关闭后再复制Cookies文件也可能白忙。Windows 上 Chromium 系浏览器的 cookie 值经历过几轮加密方案演进早期用系统提供的用户级加密接口密钥和当前 Windows 用户绑定较新的版本引入了更强的应用绑定加密机制密钥不仅和用户绑定还和应用程序本身绑定。这意味着什么你把整个 profile 目录拷到另一台机器、或者同机器另一个 Windows 账户下cookie 值大概率解不开浏览器只能把它们当成无效数据丢弃。表现就是“文件明明在登录态没了”。我的建议很直接跨环境迁移登录态永远优先走“导出为 JSON 重新注入”这条路径不要碰二进制数据库文件。下面实操部分我会给出具体代码。3. 上手复现三种典型现场与验证方法光讲原理容易飘我带你实际复现一遍。这几步做完你对 cookies 隔离的感知会从“听说的”变成“亲眼见的”。3.1 用命令行开两个独立实例直观看到隔离Windows 上打开命令提示符直接指定不同的用户数据目录启动C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe ^ --user-data-dirD:\edge-profiles\p01 ^ --no-first-run --no-default-browser-check再开一个窗口把路径换成p02。现在两个窗口里的 Edge对你来说就是两台不同的浏览器。在 p01 里登录任意站点切到 p02 刷新依然是未登录。这不是异常是预期行为。顺手打开任务管理器切成“详细信息”页签你会看到一堆msedge.exe进程注释列会标明哪个是浏览器进程、哪个是渲染进程、哪个是 GPU 进程。同一个窗口背后往往有七八个甚至十几个进程这就是“多进程”这个词在你机器上的真实样子。3.2 Python 多进程自动化里最常见的翻车写法我见过最多的错误写法长这样用multiprocessing起 4 个进程每个进程里启动一个浏览器为了“干净”每个都给了独立的 user-data-dir然后在其中一个进程里登录指望其他三个能用上登录态。import multiprocessing as mp from selenium import webdriver from selenium.webdriver.edge.options import Options def task(idx): opts Options() opts.add_argument(rf--user-data-dirD:\edge-profiles\p{idx}) # 致命一行 driver webdriver.Edge(optionsopts) driver.get(https://example.com) print(driver.get_cookies()) driver.quit() if __name__ __main__: with mp.Pool(4) as pool: pool.map(task, range(4))p0、p1、p2、p3四个目录互相独立cookies 自然各是各的。而且每个进程还各自吃几百兆内存4 个进程跑起来16G 的机器就开始告警了。正确的思路有两种要么大家共用同一个 profile接受串行化要么由一个“登录进程”产出登录态再分发给所有工作进程。第二种更实用后面细讲。3.3 IE 模式标签页为什么拿不到普通标签页的 cookie这个坑非常典型。当你在 Edge 里打开一些老系统页面时顶部会出现提示条大意是当前页面正在用兼容模式渲染建议改用标准模式浏览。这个兼容模式就是 IE 模式。它背后的实现方式和普通标签页完全不同IE 模式会拉起到一套更接近传统网络组件的独立进程cookies 走的是系统里另一套存储机制和 Chromium 的 Cookies 数据库不是同一个账本。所以你在普通标签页里登录了切到 IE 模式页面里依然是未登录反过来也一样。如果你的自动化脚本需要操作这类页面必须单独处理它的登录流程不能指望复用普通标签页的会话。我当时的做法是给 IE 模式页面单独跑一次登录把拿到的凭证用另一种方式保存下来而不是硬啃 cookie 共享。3.4 用开发者工具确认 cookie 到底存在哪想验证某个 cookie 是不是真的落到当前 profile最快的办法是打开开发者工具。按 F12进入应用面板左侧能看到存储分类展开 Cookies 就能看到当前站点在当前上下文里的所有条目Domain、Path、Expires、Size、HttpOnly、Secure、SameSite 一目了然。再配合地址栏的存储查看功能可以更细地看到各来源占用的存储空间。如果你在这里看到 cookie 存在而另一个实例里看不到说明确实是 profile 层面的隔离而不是写入失败。提示排查时先确认“当前标签页属于哪个 profile”比对着代码找 bug 效率高得多因为很多所谓的代码问题其实是环境问题。4. 解决方案按场景选别一刀切知道原因之后方案就清晰了。但我想强调一点没有万能方案选错方案比不改更糟。下面按场景给。4.1 场景一需要共享登录态那就只留一个实例如果你的业务是“登录一次后续所有操作都基于这个登录态”最省事也最稳的做法是一个 profile一个浏览器实例多个标签页或页面复用同一个上下文。在自动化框架里这对应的是“一个 browser 对象 多个 context 或多个 page”。同一个 browser 下新建的页面共享同一个 cookie 存储登录一次全部生效。这个方案的代价是无法真正并行因为同一实例内的操作本质上是串联的。但说实话很多业务根本不需要真并行。请求间隔、反爬限制、页面渲染速度这些因素加起来瓶颈往往在服务端响应不在你的并发度。硬堆进程只会让机器更卡成功率更低。4.2 场景二需要并行隔离用多 profile 加集中式登录态分发如果确实需要并行正确姿势是“登录一次 → 导出登录态 → 分发到多个独立工作进程”。登录进程只负责一件事打开一个持久化上下文人工或自动完成登录然后把 storage state 导出成一个 JSON 文件。这个 JSON 里包含 cookies 和 localStorage 的快照是纯文本可跨进程、跨机器使用完全绕开了加密那套麻烦。工作进程各自启动独立的浏览器上下文加载这个 JSON就拥有了同样的登录身份同时彼此之间页面、缓存、localStorage 完全隔离互不干扰。这是我目前最推荐的方案。4.3 代码实现导出与注入登录态用 Playwright 配合 Edge 的实现大致如下。登录阶段from playwright.sync_api import sync_playwright with sync_playwright() as p: ctx p.chromium.launch_persistent_context( user_data_dirrD:\edge-profiles\login, channelmsedge, headlessFalse, ) page ctx.new_page() page.goto(https://example.com/login) input(完成登录后按回车继续...) ctx.storage_state(pathstate.json) # 导出 cookies localStorage ctx.close()工作进程阶段注意这里是先launch再new_context把storage_state传进去from playwright.sync_api import sync_playwright from concurrent.futures import ProcessPoolExecutor def worker(task_id): with sync_playwright() as p: browser p.chromium.launch(channelmsedge, headlessTrue) ctx browser.new_context(storage_statestate.json) page ctx.new_page() page.goto(https://example.com/list) # 这里已经带着登录态了 print(task_id, page.title()) browser.close() if __name__ __main__: with ProcessPoolExecutor(max_workers4) as ex: ex.map(worker, range(4))这里有个容易踩的坑launch_persistent_context本身不接受storage_state参数因为持久化上下文的身份来自 user-data-dir你不能既指定目录又指定状态文件。想要注入登录态就用非持久化的launchnew_context(storage_state...)组合。我第一次写的时候在这里卡了很久反复报参数错误。如果用 Selenium思路一样只是接口不同cookies driver.get_cookies() # 导出 # 另一个进程里先访问目标域再注入 driver.get(https://example.com) for c in cookies: c.pop(sameSite, None) # 部分 driver 版本对字段挑剔 driver.add_cookie(c) driver.refresh()顺序很重要必须先在目标域名下打开一个页面才能往这个域加 cookie否则会抛出无效域名的异常。4.4 多进程还是多线程先算一笔资源账很多同学一上来就用多进程理由是“多进程才能并行”。但在浏览器自动化这个场景里这个结论不一定成立。先看任务类型。如果你的工作主要是等网络响应、等页面加载那是典型的 IO 密集多线程或者异步就够了Python 的 GIL 在 IO 等待时会释放多线程能拿到不错的并发度。只有当你在做大量 CPU 密集的事情比如本地解析大文件、图像处理、复杂计算多进程才有明显优势。再算内存。一个 headless 的 Chromium 实例空闲状态大概吃 150 到 400MB页面复杂一点、标签页多一点单个实例冲到 800MB 甚至 1GB 都不稀奇。16GB 的机器系统和其他软件占掉 4GB剩下 12GB按每个实例 600MB 保守估算理论上限 20 个但实际留足余量我一般控制在 4 到 6 个并发。超过这个数会发生什么频繁的内存回收、可能触发磁盘交换、浏览器进程被系统杀掉、脚本报连接中断。表现是成功率反而下降你会以为是反爬其实是机器扛不住。注意并发数不是越大越好先按“可用内存 ÷ 单实例峰值内存 × 0.6”估一个上限再从这个小数字往上调比从大数字往下砍靠谱。4.5 进程间通信能帮上什么忙帮不上什么忙multiprocessing提供了一套进程间通信的手段队列、管道、共享内存、管理器对象都能用。这些东西可以传递数据、传递任务、传递状态标记但有一条边界要认清它们传递不了浏览器内部的 cookie 存储。原因很简单cookie 存储是浏览器进程的私有状态你的 Python 进程只能通过外部接口去读写它比如框架提供的 cookies 接口、storage state 导出、或者远程调试协议。你不能用管道把一个活着的 cookie jar 塞给另一个进程。所以正确的分工是进程间通信负责传“任务和结果”登录态这类需要持久化的东西走文件或数据库中转。我通常会把导出的 state.json 放在一个固定路径配合文件锁或简单的完成标记让工作进程知道“登录态已经准备好了”避免它们空跑。5. 常见问题速查与踩坑心得前面讲了原理和方案这一节是纯粹的实战经验。我把反复被问到的和反复踩到的都列出来遇到问题时可以直接对照。5.1 问题速查表现象大概率原因处理方向两个窗口登录态不同步user-data-dir 或 profile 不同统一目录或改为导出注入浏览器启动后瞬间退出同一 user-data-dir 被占用一目录一实例或先关掉旧实例复制 Cookies 文件后仍未登录加密绑定 未落盘改用 storage state 导出注入注入 cookie 报域名无效未先访问目标域先goto同域页面再注入登录后立刻刷新就掉线会话 cookie 未落盘或未注入完整关闭浏览器后再导出或完整传递全部 cookieIE 模式页面始终未登录存储机制独立单独处理 IE 模式的登录流程并发跑一会儿全挂内存不足导致进程被杀降低并发数加长重试间隔重启电脑后登录态丢失会话 cookie 异常退出检查是否正常关闭浏览器表格里每一条我都亲身遇到过至少一次。特别是“复制文件后仍未登录”这条浪费了我大半天时间最后才明白是加密和刷盘时机两个因素叠加造成的。5.2 三条我给自己定下的红线第一条红线绝不多个进程同时指向同一个 user-data-dir。哪怕只是短时间重叠也可能造成配置损坏、扩展状态错乱、甚至 profile 打不开。自动化脚本里一个 profile 同一时刻只允许一个实例持有。第二条红线绝不靠复制二进制数据库文件来迁移登录态。跨机器、跨账户、跨版本都可能失效而且失败时没有任何明确报错只有“莫名其妙没登录”排查成本极高。JSON 导出虽然多几步代码但可靠性完全是另一个量级。第三条红线绝不把并发数设到内存上限。留出至少 40% 的内存余量给系统和浏览器自身的峰值波动。浏览器在渲染复杂页面时内存会短时间飙升你要是压着上限跑崩溃只是时间问题。5.3 关于清理和重装cookie 到底会去哪经常有人问如果我把浏览器卸载重装cookies 是不是就清干净了答案通常是“不一定”。因为用户数据目录属于用户数据不属于程序安装目录。常规的应用卸载流程主要处理程序文件用户数据目录往往会被保留下来。所以你重装之后打开浏览器如果还是同一个 Windows 账户、同一个用户数据目录之前的登录态、历史记录、书签可能都还在。反过来说如果你想彻底清掉浏览器里保存的登录状态只卸载程序是没用的得去清理用户数据目录或者直接在浏览器里用清理浏览数据的功能勾选 cookies 和站点数据。这两件事要分开处理别混为一谈。至于把浏览器换成另一个版本、或者装到另一个路径同样不影响用户数据目录的位置它们之间是解耦的。理解这一点你在做环境迁移时就不会莫名其妙地“带着旧登录态”或者“以为清干净了其实没清”。5.4 我个人踩过的几个坑有一个坑我印象特别深早期做批量任务时我用multiprocessing加fork方式启动子进程父进程里已经初始化过浏览器驱动对象结果子进程复制了父进程的内存状态拿到一个“半个活着的”驱动句柄调用时各种诡异的超时。后来改成在子进程内部完整地创建和销毁驱动问题消失。跨平台的多进程启动方式差异很大涉及外部资源时尽量让每个进程自给自足。另一个坑是关于刷盘时机的。有一次我需要把登录态从测试环境搬到正式环境图省事直接在浏览器还开着的时候复制了 profile 目录结果新环境里登录态是旧的某些接口一直返回权限错误。后来改成让浏览器正常关闭、等几秒再复制才拿到完整数据。但即便这样加密绑定那关还是没过最终还是回到了导出 JSON 的方案。还有一个关于 IE 模式的教训。当时接到一个老系统的自动化需求脚本在标准模式下怎么都登录不上页面元素也对不上。排查很久才发现页面上有个提示条指明当前页面运行在兼容模式。改成单独处理这个模式的登录流程后一切正常。这类页面的行为逻辑和现代页面差异很大不要试图用同一套代码通吃。如果你也在做类似的多进程浏览器自动化我建议先把“登录态从哪来、到哪去”这条链路单独画清楚再写并发逻辑。顺序反了后面调 bug 的时间会成倍增加。