H3.10.1bounded automatic retry设计研究
自动重试需有次数上限
别名: 重试上限 · retry cap · 有限重试
概念解释
瞬时故障值得自动再试，但自动重试必须在有限次之后停下来，把控制交还给人。没有上限的重试会把一次失败变成无限等待、把服务端打成更大的故障、让人无法区分「还在试」和「已经死了」。这条只管次数与停止，不管哪些操作根本不该自动重试，也不管重试期间能不能取消。
机制
自动重试的假设是故障短暂且独立。真实故障常是持续的：鉴权失效、配额耗尽、对端已挂。每次重试都在同一错误上再付一次等待，注意被「转圈」占住，人既不能改参数也不能离开。对服务端，无界重试是同步的惊群。上限把「值得赌的瞬时」从「需要换策略的持续」里切开：到点之后表面变成结果加下一步，而不是永远的进度。退避（越来越长的间隔）降低冲击，但不能代替上限——退避只是把无界拉长。
怎么研究
注入持续故障，比较无上限、固定 N 次、带退避的 N 次。
自变量：最大次数、间隔策略、失败是否在界面上变成终态。 因变量：用户放弃时间、重复请求到达服务端的次数、把持续故障当成「还在加载」的比例。
实验室网络可以人为抖动。要另设一个永不恢复的条件，专门看上限是否真的把控制交还。
边界
下载或同步这类用户明确允许的长任务，上限可以按时间而不是按次数，但仍需可感知的停止与摘要。关键路径上的一次瞬时超时，上限可以是 1 或 2；把上限设成几十，等于没有。客户端时钟被调乱时以次数为准，不要只靠墙钟。
怎么落地
- 为每类自动重试写下最大次数和达到后的表面：停止转圈、给出失败结果和下一步。
- 间隔用退避，但把总尝试次数硬编码进客户端，禁止在失败循环里重入无上限。
- 同一用户可见的请求不要在多个层（页面、SDK、网关）各重试一遍而不协调，总次数按人感知的那一次计算。
- 验证：把对端关掉，看界面何时停止重试、服务端日志里同一请求出现几次。转圈超过约定次数或日志在涨，上限就没生效。