多账号采集的关联风险来源与可控变量

电商数据采集分两类：不需要登录的公开页面采集，和需要登录态的采集，比如查看竞品后台数据、获取个性化展示后的结果。

前一类控制好频率基本就够。后一类一旦涉及多个账号，真正决定成败的就不再是脚本写得多聪明，而是这些账号能不能各自独立地存在。这一层没做好，限流和封禁看起来就是随机的，你改脚本、降频率、换选择器都不会有改善。

风险是从哪来的

平台判断几个账号是不是同一批人在操作，靠的是交叉验证：网络地址、浏览器与设备特征、Cookie 与会话数据、操作习惯，任一类高度重合，就可能被归到同一个控制人下面。

这里要先划一条线。判定逻辑会持续更新，靠临时技巧去对冲，收益很短而代价很高，所以下面不讨论怎么绕开风控。值得讨论的是另一件事：把风险来源摆清楚之后，哪些是我们能控制、能长期稳定的变量。这些变量决定的，是多个合法账号之间会不会互相牵连。

设备与浏览器特征

最容易出错的组合是在同一台机器上开多个窗口登录不同账号。即使清了缓存或者开无痕模式，这些窗口仍然共享同一套系统环境和浏览器数据，特征还是重叠的，平台看到的是一台设备在反复切换身份。

可控的做法是让账号有自己的环境：一个账号对应一个独立环境，指纹、Cookie、本地存储互不串用。关键在于这个环境要按账号固定下来，而不是每次启动随机生成一套。随机生成的组合常常自相矛盾，时区、语言、分辨率、UA 互相打架，看起来比稳定不变更像异常。

说到底，稳定性来自一致性，不来自随机性。

网络出口

出口要和账号绑定：一个环境一个出口，而且出口的地区要和账号资料、时区、语言成套。多个账号虽然环境分开了、却共用同一个出口，前面的隔离基本白做。

出口还要相对稳定。频繁换地区会让账号所在地这个信号变得无法解释。选出口的时候，住宅类地址通常比数据中心类更容易被当作正常用户访问，同时要留意别用到已经被大量使用过的地址，这类地址本身已经被重点监控。

Cookie 与会话

会话状态本身就是一份身份档案。多个账号共用一份 Cookie 或本地存储，等于在它们之间架了一条明线，环境分得再干净也拦不住。

新环境里的会话也不适合一上来就高强度使用。先有一段正常浏览积累出来的历史，再逐步增加任务量，这条经验在采集以外的场景同样成立，账号有没有使用历史，直接决定了它能承受多少动作。

请求节奏

请求密度是行为层面的信号。脚本的典型特征是节奏整齐：固定的访问间隔、固定的页面顺序、从不产生采集之外的行为。这种整齐不是靠加随机数就能解决的，问题在于整体量级。

可控的方向是把任务量控制在一个合理范围内：错开不同账号的执行时段，别让所有账号在同一时间一起拉满，页面之间留出合理的间隔，区分开优先级高和低的采集任务。这条线的边界其实很清楚，就是别让对方服务因为你的采集受到压力。反过来，任何以影响对方服务为代价换来的采集速度，本身就不成立。

为什么按账号固定环境比随机切换更稳

随机切换的动机是每次都换个样子，但关联判定看的是各维度之间是否稳定、是否自相矛盾。一个账号今天从这里出去、明天从那里出去，特征组合每次都不一样，这本身就是异常信号。

固定环境的逻辑正好相反。账号从注册起就有一套不变的身份：固定的环境、固定的出口、成套的时区与语言、慢慢积累的会话历史。时间越长，这是一个正常用户的判断越容易成立。环境层的价值就在这里，它是长期的稳定性，不是花哨的变化。

这也顺带解释了为什么采集脚本不该自己管浏览器实例。环境要能被独立调度，才能给不同账号分配专属环境；环境状态要能查询，才能发现异常的环境和已经失效的账号；环境要能被回收，否则长期运行会攒下一堆僵尸实例；采集任务重试的时候往往需要换环境重试，这只有在环境可独立调度时才做得到。PurpleMark 在这类结构里就是环境资源这一层，脚本只管采集逻辑，身份和资源交给环境层。

合规边界

最后这几条比前面任何优化都重要。

遵守目标站点的服务条款与 robots 协议。不少电商平台在条款里明确限制自动化访问，动手之前先确认你的使用方式是否被允许。只取公开的商品、价格、库存类信息，不采集个人信息。不绕过技术保护措施，遇到验证码、加密接口这类防护，应该调整采集策略或者去申请授权，而不是想办法破解。控制请求频率，无论手上有多少个账号，都不应该影响对方服务的正常运行。

这些讨论的前提是多个合法账号如何各自独立、互不干扰，而不是如何规避平台规则。前者是运营卫生，后者是另一回事。