I2.13.4repeated failure as systemic设计
反复失败的模式提示可能是更系统性的问题而非偶发网络波动
别名: 系统性失败 · 不是偶发波动 · failure pattern
概念解释
偶发失败是一只掉包、一次 503，退避和转交就够了。反复失败是同一操作、同一类错误、在一段时间内重复出现——每次打开这一页都挂、每条上传都 413、全应用的写都 401。模式在说：不是网抖了一下，是配置、配额、鉴权、客户端版本或对端在维护。继续把每一次都当偶发，人会空转在「再试一次」上，真正要换的策略（登录、升级、换文件、等维护结束、找人工）不会出现。
机制
偶发和系统的生成过程不同。偶发的重试会在分布上偶尔成功；系统的重试成功率接近零，时间也救不了。人从单次失败里读不出分布，只能靠产品把多次收成模式：计数、同一错误码聚类、同一端点连续失败。读成模式之后，文案和动作要换挡：从「再试」换成「这可能是账号过期 / 文件超出上限 / 服务在维护」，并给出那一档的动作。不换挡，就近重试仍然正确，但正确在错误的问题层面上——局部的锤子打在结构的钉子上。
模式还可以跨模块。主列、侧栏、提交一起 401，是会话死了，不是三个独立的加载失败。各自重试会把一个人拆成三次登录。升到会话层，才是对模式的回应。
边界
弱网地区的「反复」可能仍是偶发的密集版，模式要能被网络恢复打散：一有稳定连接，成功率回来，就不要升到「系统坏了」。客户端时钟不准导致的证书错误看起来像系统，修的是时间，不是重试。单次就该当系统的错误（明确的维护页、强制升级）不必等模式形成。不要用模式去吓偶尔失败两次的人；阈值要过「偶发密集」那一档，比如同会话同端点连续 n 次，或跨模块同一鉴权错误。
怎么落地
- 记录同会话、同端点、同错误类的连续失败。过阈值后换文案和主动作，不要永远「再试一次」。
- 跨模块同一鉴权或维护码，升到会话或整页说明，收起各模块的分散重试。
- 给出与模式匹配的出口：重新登录、选择更小的文件、查看状态页、联系支持；网络恢复后清掉模式，回到偶发处理。
- 验证：连续失败同一上传 413 五次。第五次若仍只有「再试」且会再发同一文件，模式没被读出来。应出现体积/格式说明和换文件。再造全应用 401，应是一次登录，不是每个模块一颗重试。