动态和静态搭着用，混合池怎么分、比例怎么定

多数团队一开始只用一种资源：要么全是动态，图便宜；要么全是静态，图省心。等业务跑起来才发现，两种需求其实同时存在——一部分任务要稳定，一部分任务要分散。把它们拆开各用各的，成本和稳定性往往能同时改善，这就是混合池的由来。

混合池的核心是把任务按”要不要连续性”分流

搭建混合池的第一步不是买资源，而是给任务分类。需要登录、需要维持身份、需要提前备案出口的，归到静态一侧；批量、无状态、可以随时重来的，归到动态一侧。分类做完，比例自然就有了：静态承担的是”身份类”任务，数量取决于你有多少个需要长期维护的身份；动态承担的是”规模类”任务，数量取决于你的吞吐需求。这两条线互不干扰，扩容时也各算各的账。

比例怎么定，从两个数字倒推

静态侧的数量等于”需要长期维持的并发身份数”，不含备份的话，有多少个身份就配多少条；动态侧的数量等于”峰值吞吐 ÷ 单地址并发”，再加两成冗余应对失效重取。两个数字加起来就是你的资源盘子，哪一侧涨了就补哪一侧，不必按比例同步扩张。实际落地中，多数业务是静态少、动态多，数量比在 1:5 到 1:20 之间都比较常见。

交接处最容易出问题

混合池的难点不在两侧内部，而在两者交界的地方：同一个账号一会儿走静态、一会儿走动态，出口忽变，比全程用动态还危险；任务从动态侧发起、却在静态侧收尾，两边的日志对不上，排查时一头雾水。解决办法是给身份与资源建立绑定关系并在程序里强制校验——属于某个身份的请求只能从绑定出口发出，越界直接拒绝并报错。

1. 先做任务分类：按是否需要连续性把任务切两半
2. 再算两侧数量：静态看身份数，动态看峰值吞吐
3. 然后做绑定：身份与出口一一对应，程序层强制校验
4. 最后留隔离：两侧日志分开记，避免排查时混淆

混合池像一支队伍里的正规军和游击队：守阵地、亮身份的活归正规军，铺面、打穿插的活归游击队，各干各的，别让同一个人上午穿制服下午换便装。

与 IP 代理的关系：动态与静态各有擅长，按任务是否依赖连续性分流、分别测算数量并做好身份与出口的绑定，能让两类代理资源在同一业务中协同工作，兼顾成本与稳定。