[AthenaHibou]

摘要

• 账号切换方式支持不切换、MAS 切换（推荐）、ok-ww 逐账号切换和批量切换，并提供各模式的悬停说明。
• 沿用 MAS 的逐用户配置；逐账号模式分别运行和重试，批量模式仅补跑未完成账号，保留逐账号运行限制与统计。
• 按账号展示节点详情和切换失败原因，完善手动中止后的结果汇总与通知，保留已完成账号的成功结果和原始历史日志。
• 自动转换完整大陆手机号，支持登录列表中的掩码手机号和邮箱；对不支持或重复的账号标识明确报错，上游明确拒绝原生切号入口时提示检查版本或改用 MAS，并停止重试。

Closes #1697

验证

• ok-ww 相关 85 项回归通过，覆盖成功账号补跑排除、手机号校验、逐账号派发、限次与跨日计数、中止收尾、关闭节点后的原始历史日志、不兼容提示及旧日志隔离。
• 前端相关 2 项测试、类型、格式及更新日志检查通过；lint 仅有 dev 已有的 QueueDeleteButton.vue 警告。
• 作者已实机验证正常运行、失败和手动中止后的通知；新增不兼容提示通过隔离日志回归验证，未再次进行实机验证。
• 全量回归首次运行有 4 项失败、8 项环境错误；启用 UTF-8 后对相关测试复跑，剩余 3 项子进程依赖缺失，已在未修改的 dev 基线复现。

兼容性说明

暂时依赖 ok-ww 的多账号配置与结果文件格式；待上游提供稳定接口后替换。不以普通登录失败或启动超时推断版本不兼容。

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1890

这版把原生逐账号与批量补跑都接上了，已成功账号会从下一轮名单移除，也没有把单个日常任务完成误当整批成功，这两处处理挺认真喵。不过配置恢复还差一步：批次文件写入后，崩溃恢复使用的指纹没有一起更新，需要先修好；批量模式还把单账号总时限当成了整批时限。

调度器负责选出可运行账号并保存、恢复原生配置；BatchProxy 组织原生批次、读取各账号结果，再复用 AutoProxy 的启动、重试和收尾。下面的问题发生在批次配置写入与公共恢复机制的衔接处。

[逻辑 · P2] 批次写入后未刷新注入指纹，硬退出后无法恢复原生配置

位置：BatchProxy.py:139–149。

静态核对这条路径：选择任一种原生切号模式 → BatchProxy.set_okww() → 父类下发配置并调用 mark_native_config_injected() → write_attempt() 又改写 MultiAccountConfig.json 和 MultiAccountResults.json，但没有重新记录指纹。公共指纹包含目录内所有文件，并未排除这两个文件。

只要这次写入改变了目录内容，此后 MAS 被强退或断电，即使 OK-WW 还没启动，下一轮 manager.prepare() 的恢复也会遇到“现场既不等于注入指纹、也不等于原始指纹”。recover_native_config 因而按外部修改跳过恢复，并清除恢复快照，留下 MAS 覆盖后的配置。正常退出时的 finally 可以恢复，但覆盖不了硬退出；这是新增批次写入破坏既有保障，不依赖上游是否改写文件。

修复应由 BatchProxy 的批次注入步骤承担，并复用现有快照机制：至少让记录对应全部批次文件的实际下发内容，同时处理两份文件写入及指纹更新之间的中断，不能只在最后刷新一次就宣称恢复完整。请分别覆盖写入中途、写完但尚未更新指纹、更新后尚未启动上游三个中断点；再次启动时应能恢复原目录，或保留可恢复的原始快照，而不是把已知注入误判为用户修改后直接清掉。

[逻辑 · P2] 批量模式让全部账号共用一个单账号硬超时

位置：manager.py:314–329。

批量模式把全部参与账号放进一个 BatchProxyTask，但它继续继承 ScriptAutoProxyBase 的硬超时包装：整个 main_task() 只计一次 HardTimeLimit。配置和界面仍把这个值定义为“单账号运行总时限，包含等待和全部重试”。

静态场景很直接：用户设置 10 分钟，A、B 各正常运行 8 分钟。逐账号模式都能完成，批量模式却会在 B 运行约 2 分钟时终止整批。这个计时不因持续产生日志而延长，后面的账号因此失去本应有的运行时间；账号越多越容易触发。

批次入口需要明确并落实对应的时间预算，不能直接沿用单账号计时。如果这里有意采用整批共用预算，也请让配置说明和界面明确表达，并提供适合多账号的设置。补一个两个账号各自未超时、累计超过单账号上限的场景，就能把这条区别守住喵。

非阻断建议

账号编辑页的“当前启动参数”仍固定显示 -t 1 -e，而两种原生模式实际用 -t MultiAccountConfigTask -e。顺手按托管模式显示实际值，或注明这里只是普通日常模式示例吧，免得排查时照着复制了另一种入口。

本次是静态源码与调用链检查，未执行项目代码或测试；作者提供的测试与实机结果不当作独立复现。当前可见 Actions 只有标签工作流，没有行为测试结果。另外三份 i18n JSON 与当前目标分支存在合并冲突，需要解决后再核对集成状态。

—— dot酱敬上 🐾

[AthenaHibou]

已核实并处理本轮审核，提交 3840b56。

• 单账号硬超时被整批共用、日志回调提前唤醒造成失败补跑遗漏：均已用回归复现并修复，相关 inline 线程已回复。
• 新增审核指出的注入指纹问题属实。批次文件下发完成后更新最终指纹；写入中途或写完但尚未记录指纹时，恢复逻辑保护当前现场，并把原始快照另存为 Temp.unresolved（已有副本时追加序号），供人工核对恢复，不删除恢复依据；最终指纹已更新且上游尚未启动时自动恢复。三个中断点均有旧行为失败、修复后通过的回归证据。此处对无法确认的现场保留副本，不宣称全部中断场景都会自动恢复。
• 将账号页固定参数标为普通日常模式示例，并明确原生模式实际参数。
• 已普通合并最新 dev（bda55de47），三份词表冲突保留双方新增词条，未改写历史。

验证：ok-ww 与公共配置快照回归共 98 项通过；前端相关 2 项测试、typecheck、format:check、Ruff 及更新日志检查通过；lint 保留 dev 现有 QueueDeleteButton 警告。本轮未执行真实游戏运行，远程 CI 以本次 head 为准。

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1890 · 复审

宝宝，上一轮按住的两处这次都补上啦。批次文件写完后会重新记录注入指纹；写到一半或尚未记指纹就中断时，原始快照会另存为 Temp.unresolved，留给人工核对恢复，不再直接丢掉。整批硬时限也按最初参与账号数计算，补跑时不会因为名单缩短而缩水，dot酱这两爪可以松开了喵。

这轮还把日志回调的唤醒放到了账号结果归档和整批判定之后，避免主流程先停止监控、取消尚未完成的结果处理。普通逐账号流程保留原来的默认唤醒方式；公共恢复函数的新选项也只有 OK-WW 显式启用，没有改动其他专项默认行为。

dot酱静态核对了旧问题、三个写入中断点的回归断言、批次超时与结果回调链，并检查了与当前目标分支的集成，未发现新的必须修改项。启动参数文案已改成普通日常模式示例，原先的三语合并冲突也已消除。

当前提交的八项检查均已通过。已读取 CI 实际测试日志：Windows 为 1778 passed、2 skipped，Ubuntu 为 1751 passed、29 skipped。dot酱没有执行项目代码或真实游戏；这些结果能支持代码回归检查，不替代真实多账号切换验收。无法辨认现场归属时仍需人工恢复留存快照，这一点没有写成全自动恢复。后续按仓库条件和维护者判断合并就好啦。

—— dot酱拍拍爪敬上 🐾