多窗口同时跑，最容易出问题的是地址混用。两个窗口共用一条代理IP线路，登录状态会互相干扰，表现是隔一段时间就被要求重新验证。窗口数一多，谁在用哪条线路就说不清了。解决的办法不复杂：把窗口和线路的对应关系固定下来，写在配置里，不靠记忆。
一个窗口一条线路，是最省心的分法。
固定对应关系有两种做法。一种是把线路参数直接写进每个窗口的启动参数，窗口一开就带着自己的地址，这种方式最稳，改起来要改启动脚本。另一种是给每个窗口配一个独立的客户端实例，各自连各自的线路，管理成本高一些，好处是互不影响。两种都能用，选哪种看窗口数量。
- 先给每个窗口编号，编号写进窗口标题
- 再把编号和线路参数做成一张对照表
- 启动时按编号取对应的参数，不手工填
窗口标题要带编号
窗口标题带编号，是最省事的区分方式。任务跑起来之后，看一眼标题就知道这个窗口走的是哪条代理IP线路。不带编号的话，十个窗口长得一模一样，出问题只能一个个点开看参数。编号规则简单到只有数字也行，关键是唯一且不重复。
对照表放在哪
对照表要放在所有窗口都能读到的地方，别放在某一个窗口的目录里。放在共享目录或者统一的环境变量里，窗口重启也能读到。放在本地文件里，换机器就丢了一半，还得重新对一遍。
编号、对照表、启动参数，三样缺一样，固定关系就守不住。
地址混用的表现
混用的表现有三种：登录状态莫名失效、同一操作在两个窗口结果不同、日志里的来源地址对不上号。三种里最容易被忽略的是第二种，结果不同往往被当成业务问题查很久。看到这类现象，先查窗口和线路的对应关系，是最快的路径。
窗口数量上来之后
窗口超过十几个，人工对应就不现实了，得靠脚本按编号批量生成配置。脚本生成的好处是复制粘贴的错漏没有了，坏处是脚本本身要维护。脚本出错的表现更隐蔽：一个变量取错，所有窗口的代理IP地址都跟着错，排查时反而更费时间。
把窗口和线路的固定关系做扎实，多窗口跑起来才谈得上稳。关系不清楚的时候，窗口越多，出问题的面越大。