脚本能把重复操作自动化，也会把配置上的问题一起放大。手工操作时一小时点几十次，节奏天然带点随机；脚本跑起来一小时几百次，间隔精确到毫秒，规律得不像人。所以要上脚本，先看代理IP这一侧能不能跟上，跟不上就会把线路压垮，或者把自己变成最显眼的那个，两头都不划算。
脚本放大效率，也放大规律。
- 先给脚本设一个上限并发，别用默认值
- 再给每步操作加随机间隔，别用固定毫秒
- 最后加失败退避，别无限重试
上限并发是最重要的一条，尤其是代理IP的连接数。多数脚本的默认并发是按最快跑完来设的，实际跑起来会把线路的连接数占满，其余实例全部排队。压到一半甚至三分之一，整体耗时增加不多，稳定性差别很大。
节奏为什么要随机
固定间隔是脚本最明显的特征。每一步都精确相隔五百毫秒，连续一小时，这种规律手工做不到，也不像正常使用。加个随机浮动，间隔在三百到八百毫秒之间变，规律性立刻就没了，成本只是十几行代码。
随机要有范围，不是越乱越好，浮动幅度控制在两倍以内最自然。浮动太大反而显得刻意，像在刻意躲什么。两倍以内的抖动，跟人工操作的节奏比较接近，跑一天下来看不出规律，这一步比随机算法本身影响更大。
还要注意别让所有实例用同一个随机种子。十个实例的间隔序列完全一样，等于没有随机。每个实例用自己的种子，序列才是真的不同。
失败了怎么退
脚本的默认重试往往是立刻重来，这在线路抖动的时候会变成重试风暴。失败之后先等，等的时间逐次翻倍，翻到上限就停下来报错。停下来比继续试有价值，继续试只会把日志刷满。
并发和线路怎么配
代理IP的并发上限不能超过线路的连接数余量。先测单条线路能同时建立多少连接，再按实例数分配，每个实例的并发不要超过余量的三分之一。留三分之二是为了应对突发，脚本的突发往往比手工大得多。
跑起来之后看什么
看三样：被拒比例、平均单步耗时、失败集中在哪里。被拒比例升高说明并发超了；单步耗时变长说明线路在挤；失败集中在某一步，说明那一步的参数有问题。三样都在日志里，加几行统计就能出来。
还要看时段。同一套脚本在凌晨跑得好好的，晚上就跑不动，说明问题不在脚本而在容量。这种情况调脚本没用，得错峰或者加线。
什么时候该停
被拒比例连续两天超过百分之五，或者失败率超过一成，就该停下来看。继续跑只会积累无效请求，既浪费时间也可能让线路被降级。停下来查半天，比硬跑一天划算。
日志方面，留最近七天的完整记录，更早的只留统计。完整日志用来查具体某次失败，统计数据用来看趋势。两样都要，只留一样到用的时候一定缺。
脚本和环境的关系
脚本改的是行为节奏，改不了网络环境。环境没分开，脚本写得再像人也没用；环境分开了，脚本还带着明显的机器节奏，同样会被注意到。两边都要做，顺序上先环境后脚本。
先有稳定的环境，再谈脚本的效率，反过来做会一直在修网络问题。
把并发、间隔、退避三样设对，脚本跑起来才不至于拖垮线路。
