业务场景
微信自动加好友脚本，单批次接收一组 leadList 多条客资，依靠 storages 持久化集合做批次内去重黑名单。
环境
Hamibot + Rhino 1.7.15，安卓小米 9 Pro
完整现象
脚本正常执行第一条联系人，添加成功；执行 Set.add() + storages.put() 写入黑名单，日志打印写入成功、黑名单数量 = 1。
延时结束进入下一轮循环，再次调用 storages.get() 读取黑名单，偶尔读到空数组（旧缓存数据）。
使用这个过期空黑名单筛选原始 leadList → 待处理列表依旧包含已经处理完成的联系人。
取出第一条联系人，再次调用 storages.get() 做二次校验，此时读取到最新黑名单，判定此人已处理；执行 continue。
无限重复上述逻辑：筛选拿到完整原始列表 → 二次校验拦截 → 死循环卡死，不再执行下一条有效客资。
关键证据（日志体现）
同一轮循环内部，先后两次调用完全相同参数的 storages.get(batchId)，返回的数据不一致
第一次（筛选阶段）：[] 空集合
第二次（二次校验）：["qhj13981866488"] 有数据
初步判断疑点
storages 读写存在异步缓存 / 延迟落盘机制；
storages.put() 返回成功、打印日志 ≠ 数据立刻持久化完成；短时间内连续读取可能命中旧缓存。
当脚本出现「无障碍连接断开」触发 Rhino 休眠 / 暂停时，会放大该现象，更容易读到过期缓存。
是否存在：同一脚本实例，短间隔多次 get，数据不同步的已知 BUG？
我方已经尝试过的规避手段（均无法根治）
修复页面返回逻辑，避免微信频繁前后台切换，减少无障碍断开；
数组副本 Array.from() 隔离 Rhino 数组取值错乱；
统一数据源，删除多文件、多套黑名单冲突；
一轮循环只读取一次黑名单集合，全程复用；
增加重试次数熔断，防止永久死循环。
问题
Hamibot storages 持久化存储读写机制说明：是否有内存缓存层？put 之后多久能保证 get 读取到最新数据？
Rhino 脚本休眠、无障碍断开暂停期间，会不会导致 storages 缓存脏数据？
官方推荐替代方案：
如果 storages 存在同步延迟，使用本地 txt/json 文件读写替代 storages 是否更加稳定？
是否存在同类场景官方补丁、最佳实践？