账号是消耗品，要按库存管理
规模化协议业务的核心资产是账号池。把账号当"永久资源"用是新手最大的认知错误——账号是会疲劳、会标记、会死亡的消耗品。正确姿势是按库存管理：有入库（注册）、有养护（养号）、有服役（业务）、有退役（报废）。
生命周期设计
注册 → 养号期(7-30天) → 服役期 → 冷却期(触发风控) → 再服役/退役注册：接码平台 + 设备档案 + 住宅 IP，三要素齐全。注册成功率本身就是风控指标——同一设备/IP 批量注册必死，注册资源也要池化。
养号期：新号直接上业务是自杀。养号期做"正常用户行为"：
- 每天登录，浏览内容 10-30 分钟
- 随机互动（点赞、关注），频率模拟真人
- 完善资料（头像、昵称、简介）——资料完整度是风控的基础分
养号周期视平台风控强度：弱风控 3-7 天，强风控（电商/支付）15-30 天。
服役期：业务操作期。核心是负载控制——单号日操作量控制在真人区间（参考真实用户的统计分布），配合作息时间（别 24 小时连轴转）。
冷却期：触发风控（验证码、限流）的号进冷却期，停止业务 3-7 天只做浏览行为，等风控等级回落。
退役：严重风控（封号、人脸验证）的号退役。退役号的数据（注册信息、行为历史）要存档——分析死因，优化注册和养号策略。
数据模型
class Account:
id: str
username: str
password: str
status: str # raising / active / cooling / retired
device_id: str # 绑定的设备档案
proxy_session: str # 绑定的代理会话
created_at: datetime
last_active: datetime
health_score: int # 健康分
daily_ops: int # 今日操作数
risk_events: list # 风控事件记录账号-设备-IP 三元组绑定是铁律：一个号永远用同一套设备档案和同地区 IP，任何一项跳变都是风控强特征。
精髓一：养号行为的"真实性"来源
养号脚本的行为怎么设计才像真人？抄真人：
- 自己正常使用目标 App 几天，记录自己的行为数据（在线时段、操作类型分布、间隔分布）
- 养号脚本按这个统计分布生成行为
- 定期更新（平台风控模型在变，真人基线也在变）
拍脑袋设计的"养号行为"（比如固定每小时点赞一次）在风控模型眼里是教科书级的机器人特征。
精髓二：池子规模的计算
需要多大的账号池？按业务反推：
日业务需求量 ÷ 单号日安全操作量 = 服役账号数
服役账号数 × (1 + 冷却比例 20% + 养号补充 10%) = 总池规模例：日需 10 万次操作，单号日安全 100 次 → 服役 1000 号 → 总池 1300 号。
单号安全操作量是实测出来的：新池子从小强度开始压测，记录触发风控的阈值，取阈值的 60% 作为安全线。
精髓三：死因分析是池子的复利
每个退役号都要做死因分析：
- 注册后几天死的？（注册环节被标记）
- 做了什么操作后死的？（业务行为触发）
- 同批次/同 IP 段的号是否批量死？（资源污染）
死因归因后反哺上游：注册资源被污染就换接码渠道，业务行为触发就调低强度——池子的存活率是靠死因分析一轮轮迭代出来的。
总结
- 账号是消耗品：注册→养号→服役→冷却→退役全生命周期管理
- 账号-设备-IP 三元组绑定是铁律
- 养号行为抄真人统计分布，别拍脑袋
- 死因分析反哺上游，存活率靠迭代
交流微信：run1255