一个店铺登录态串到另一个店铺只在一瞬间。但要真正杜绝它需要的是一整套工程约束。上一篇文章聊了浏览器实例池与并发调度那套东西帮我们扛住了几十个店铺同时跑的稳定性。但很快我们又遇到了一个新问题店铺之间的环境边界到底怎么守。听起来像是个运维规范的问题——只要配置对、目录分好不就没事了但实际跑起来你会发现人是会犯错的配置是会漂移的流程里一个不小心的“跳转新页面”就可能让当前浏览器实例沾染了另一个店铺的Cookie。这篇文章专门讲我们怎么在工程层面给自动化系统做多店铺环境隔离以及如何让RPA流程具备基本的事务性保障——出了问题能回滚、能重试、不会留下脏数据。一、为什么环境隔离是店群自动化的地基做拼多多、TEMU、TikTok Shop这些平台的矩阵运营一个执行机往往要承载几十个甚至上百个店铺的自动化任务。每个店铺的环境如果做不到物理级别的隔离就会出现几种典型事故Cookie交叉污染流程A在店铺甲的页面做了操作切到店铺乙时残留的认证信息被复用缓存串扰本地存储、IndexedDB里残留上一个店铺的标识导致请求带上错误shop_id指纹特征关联多个店铺在同一个浏览器内核、同一网络环境下高频访问风控侧画像关联对于合规运营来说我们需要做的不是“绕过平台”而是让每一个店铺的运营环境看起来就像一台独立的办公电脑——这也是平台乐见的正常经营形态。我见过有的团队试图通过频繁清理Cookie和缓存来解决串号问题这只能说是一个权宜之计。真正的解决方案必须从环境创建的那一刻就做到完全隔离并且没有任何“清理”操作的依赖。二、环境隔离的四层模型我们把店铺环境拆成四个层面来分别隔离每一层都有对应的工程手段。第一层浏览器用户数据目录隔离这是最基础的。每个店铺绑定一个独立的user-data-dir里面存放所有持久化状态Cookie、LocalStorage、插件配置、浏览器偏好设置。我们的池管理器在创建实例时强制校验目录绑定关系。第二层本地网络环境隔离如果一台机器上跑多个店铺同一个IP出口本身就构成关联风险。我们的做法是为每个店铺分配独立的代理出口——注意是合规的固定IP代理而不是黑产用的秒拨。这个IP就相当于这个店铺的“办公网络”。第三层浏览器指纹环境隔离这里需要特别说明我们不会去篡改或伪造指纹那属于违规操作。我们做的是通过浏览器启动参数和插件配置让每个实例的指纹特征由独立的用户数据目录和代理IP自然决定不做额外干涉。唯一做的“工程化处理”是确保不同实例之间不会意外共享字体缓存、GPU缓存等系统级资源因为那些东西可能残留跨实例的特征。第四层执行机物理/虚拟隔离当店铺数量更多时直接走虚拟机或者容器化Windows环境让一组店铺跑在独立的OS里。这块我们后面单独开一篇文章细聊这里先聚焦在同一台Windows执行机上如何做隔离。三、环境绑定机制的代码实现为了避免人为配置错误导致两个店铺指向同一个user-data-dir我们在调度层强制实施了一套“环境指纹”机制。每创建一个新的店铺环境时目录初始化完毕我们会在目录根下写一个env.json里面包含shop_id店铺唯一标识platform平台名created_at创建时间fingerprint基于店铺ID和创建时间的哈希值这个指纹文件在浏览器实例分配前会被读取并校验如果请求任务里的shop_id与指纹文件里的不一致直接拒绝分配并告警。importjsonimportosimporthashlibdefverify_env_integrity(user_data_dir:str,expected_shop_id:str)-bool:fingerprint_pathos.path.join(user_data_dir,env.json)ifnotos.path.exists(fingerprint_path):raiseFileNotFoundError(fEnv fingerprint missing in{user_data_dir})withopen(fingerprint_path,r,encodingutf-8)asf:datajson.load(f)actual_shop_iddata.get(shop_id)ifactual_shop_id!expected_shop_id:logger.error(fEnv mismatch: expected{expected_shop_id}, got{actual_shop_id})returnFalse# 二次校验指纹哈希expected_hashhashlib.sha256(f{expected_shop_id}{data.get(created_at)}.encode()).hexdigest()[:16]ifdata.get(fingerprint)!expected_hash:logger.error(Fingerprint hash mismatch, data may be tampered)returnFalsereturnTrue这段代码很小但在我们线上一度扮演了“最后的守门员”角色。有好几次数据库配置同步出了问题就靠它拦住了一批即将串号的任务。四、代理绑定一个容易疏忽的细节很多团队在做环境隔离时代理的配置还停留在“流程里手动设置”的阶段。这非常危险因为一旦流程中途失败、重试代理可能没挂上导致真实IP漏出。我们的做法是把代理绑定从RPA流程中剥离提升到浏览器启动参数层面。启动浏览器时直接通过命令行参数指定代理cmd.extend([f--proxy-serverhttp://{proxy_user}:{proxy_pass}{proxy_host}:{proxy_port},--proxy-bypass-list-loopback# 不代理本地连接])这样一来无论影刀流程内部执行了什么样的页面跳转、iframe加载流量路径始终被操作系统级别的Chromium网络栈控制不会出现“某一步忘了开代理”的低级错误。每个店铺的代理配置连同user-data-dir都在数据库中做一条环境记录生命周期一一对应不可单独修改。这是用工程手段把正确性固化下来而不是靠人每次操作时的小心谨慎。五、自动化流程的事务性不是数据库才有事务RPA流程执行到一半失败了留下半份改过的商品标题、未提交的订单草稿比什么都没做更糟糕。传统的影刀流程脚本执行失败后默认就是“停了就停了”没有任何回滚、补偿、清理的动作。我们从一开始就意识到必须给自动化流程定义事务边界哪怕它只是一个脚本。我们的做法是将每个自动化流程拆成三个阶段准备阶段校验前置条件登录态、页面加载、数据完整性所有条件不满足直接终止不进入执行。执行阶段核心业务操作比如修改价格、回复消息、采集数据。这个阶段的操作会被记录在一个“操作日志”序列中。确认/回滚阶段如果所有关键操作成功标记任务完成如果失败根据操作日志执行逆向操作能恢复多少恢复多少并标记任务需要人工介入。以改价为例执行阶段把修改前的价格存入revert_log如果后续出现异常回滚阶段直接利用这个日志把价格改回去。defexecute_with_transaction(task,flow_func):revert_actions[]try:# 准备阶段pre_check(task)# 执行阶段forstepintask.steps:before_statecapture_state(step)flow_func(step)revert_actions.append((step,before_state))# 确认阶段confirm(task)returnTrueexceptExceptionase:logger.exception(fTask{task.task_id}failed, start rollback)forstep,before_stateinreversed(revert_actions):try:restore_state(step,before_state)exceptExceptionasrollback_err:logger.error(fRollback step{step}failed:{rollback_err})task.statusfailedraise当然不是所有操作都能完美回滚。比如已经提交的订单就很难自动取消。对于这类不可回滚的操作我们采用先行确认后执行的策略在真正执行前加一层“安全检查点”确认条件完全无误再动手。同时操作日志与业务表联动一旦出错立刻生成人工工单把损失控制到最小。六、流程内的边界守卫如何防止“串门”环境隔离解决了静态绑定问题但动态运行过程中仍然可能出现流程“主动”跳到别的店铺页面。比如流程从订单详情页点击了一个返回按钮那个返回链接可能指向了主站首页——而主站首页如果没有做好隔离可能会读取到其他店铺的Cookie残留。我们做了三件事来杜绝这种情况。第一强制绑定流程的域名白名单。每个店铺环境启动时通过浏览器扩展注入一个域名检查脚本任何非白名单域名的请求都会被拦截并报错流程直接终止。第二流程执行中不允许出现“凭空跳转”的操作。所有URL跳转必须显式声明目标地址不允许出现window.location.href被动态赋值为一个外部变量这类写法。这个靠代码审查和流程设计规范保证。第三流程结束后执行“环境净化”。这个净化不是清Cookie而是杀掉当前标签页并回到一个空白页确保下一个任务拿到的浏览器窗口是干净的起始页。这些操作都通过 CDPChrome DevTools Protocol指令精确控制。七、回收与销毁一个容易忽略的安全边界一个浏览器实例被使用过后什么情况下可以回收复用什么情况下必须彻底销毁重建我们的规则很明确正常结束的任务实例回归空闲池下个任务会先做环境完整性校验通过即可复用。出现过网络异常或代理失效的任务实例标记为“脏”立刻销毁。因为代理失效期间可能发生了直接连接导致IP漏出或Cookie关联。任何执行过涉及登录态操作的任务比如扫码登录、手机验证实例直接销毁不允许复用。哪怕登录是同一个店铺为了绝对安全也走销毁重建。销毁不是简单的taskkill。我们会先通过CDP发送关闭指令等待5秒如果进程未退出再强制kill然后递归删除user-data-dir的整个目录树确保磁盘不留痕迹。下次该店铺再需要环境时由池管理器从环境初始化脚本重新构建。八、监控与告警不只盯机器也要盯环境我们的监控看板上有一个单独的板块叫“环境健康度”包含以下指标环境指纹校验失败次数立即告警代理失效次数按店铺维度统计登录态过期次数浏览器实例因脏数据被强制销毁的比率特别是环境指纹校验失败这个指标一旦大于0说明环境绑定配置肯定出了纰漏我们会直接挂起所有涉及店铺的任务防止串号扩散。九、落地到多节点后的延伸当执行机数量增多后环境初始化就成了一个标准化流程。我们写了一个环境工厂脚本接受shop_id、platform、代理配置等参数在目标执行机上自动完成建立user-data-dir目录写入env.json配置浏览器启动参数模板首次启动浏览器进行人工扫码登录这个环节暂时还需要人工介入但可以远程操作校验登录态并拍摄快照仅用于内部审计不涉及数据外传这样任何一个新店铺从配置到就绪10分钟之内搞定而且全程操作留痕。十、最终的目标让流程变成“无状态”的服务这一整套环境隔离和事务性保障做下来我们想达到的理想状态是任何一个自动化流程拿过来一个干净的环境就能跑跑完之后环境能安全复用或销毁流程本身不依赖任何上一次执行的残留状态。换句话说把RPA流程从“状态相关的脚本”变成“无状态的服务”。这个目标还没有完全实现但框架已经基本搭完。后面要做的是让每一个流程设计都严格遵循状态外部化原则——需要的状态全部从外部传入比如数据库中任务参数执行中的临时状态全部写回任务上下文不留存在浏览器环境里。隔离不是一个技术点而是一整套工程原则的落地。它不炫酷但它是多店铺自动化能不能长久跑下去的那条生命线。作者林焱持续记录店群自动化工程中的真实实践