TG咨询脚本失败后，不要立刻无限重跑。先判断失败发生在哪一步、是否可能自行恢复，以及重跑会不会重复操作。云上移动运行环境中脚本任务的失败重试规则，核心是只重试暂时性故障，为重试设置上限，并让任务在重复执行时保持安全。
先分清失败类型，再决定是否重试
失败通常分为两类。网络短暂中断、运行节点暂时不可用、服务返回限流或超时，可能是暂时性故障；脚本语法错误、依赖缺失、定位条件错误、权限不足等，重试通常不会修复问题，应先改配置或脚本。平台若提供错误码和运行日志，优先依据两者判断，不要只看“任务失败”这一状态。
还要区分“脚本执行失败”和“任务状态未知”。例如客户端等待结果时连接中断，实际操作可能已经完成。此时直接重跑有重复提交风险，应先查询任务状态，或检查目标结果是否已产生。
一套可落地的重试规则
设置次数、间隔和总时限
对可恢复错误，可从首次执行后再重试 2至3 次开始；间隔采用指数退避，例如约 2 秒、4 秒、8 秒，并设置上限。具体等待时间要结合任务耗时、平台限流要求和超时设置调整，这不是所有云平台统一规定的标准值。加入少量随机抖动，可避免大量任务在同一时刻集中重试。
重试次数之外，还要设定任务总时限。单次运行超时后，如果总时限已到，就停止并记录原因，避免任务长期占用设备或运行配额。相关配置应与任务队列中的排队时间一并考虑。
保护重复执行
自动重试前检查脚本是否具有幂等性：同一任务执行多次，结果应与执行一次相同，或至少不会造成额外副作用。比如脚本提交表单后发生超时，先查询记录是否已创建；若结果不明，不要再次点击提交。能够控制任务标识时，可用稳定的任务 ID 查询或去重，并把“开始、完成、失败”状态写入日志。
实际配置时按这几步处理
- 查看日志：记录失败时间、错误信息、运行阶段和任务 ID，确认是启动失败、执行中断还是结果回传失败。
- 分类错误：将网络抖动、临时不可用等列为候选重试项；把语法、参数、权限和依赖错误列为先修复项。
- 检查副作用：确认重跑不会重复创建记录、重复提交操作或覆盖已有结果；不能确认时先查询实际状态。
- 配置边界：设定最大重试次数、退避间隔、单次超时和总时限，并确保重试失败后进入人工检查或告警流程。
- 小范围验证：用可控任务分别验证暂时性故障能恢复、持续性错误会停止，以及日志能区分每次尝试。
因此，云上移动运行环境中脚本任务的失败重试规则，不应只由一个“重试几次”的参数决定；错误分类、指数退避和幂等性要一起设计。先查明失败边界，再让系统有限重试，通常比盲目重复执行更稳妥。
常见问题
所有失败都应该自动重试吗？
不应该。只有可能自行恢复且重复执行安全的错误，才适合自动重试；确定性配置错误应修复后再运行。
为什么不能一直重试？
持续故障时，无限制重试会占用运行资源、增加等待时间，还可能放大重复操作。应设置次数和总时限。
重试后仍失败怎么办？
保留每次尝试的日志和错误信息，停止自动重试，检查运行环境、脚本输入及目标状态，再决定修复或人工重跑。