支付链路规格:失败场景与重试矩阵
我评审过的大多数支付规格,都用三页篇幅描写 happy path,再用一句话描写失败行为:“出错时重试”。生产环境里 80% 的事故,就是从这一句话里冒出来的。
分页浏览完整的 Spec Coding 文章归档。静态分页更利于长列表检索、抓取与直接引用。
我评审过的大多数支付规格,都用三页篇幅描写 happy path,再用一句话描写失败行为:“出错时重试”。生产环境里 80% 的事故,就是从这一句话里冒出来的。
一个团队的工程成熟度,最能看出来的时刻不是 code review,而是他们怎么描述凌晨三点出事之后的应对流程。大多数上线计划死在"我们会密切监控"这句话上——这话从来没救过谁。
我评审过的绝大多数 webhook 消费端规格,覆盖的内容只有一个端点、几乎别无其他:URL、JSON 结构,再加一句含糊其辞的“校验签名”。那不是规格。
"合理处理边界情况。"我几乎每周都能在 spec 里看到这句话。它什么都没说。QA 没法测试"合理"——他们需要具体的输入、具体的触发条件、具体的预期结果。下面是我写边界情况的方式,让 QA 不用追问一句就能把它们变成测试用例。
静态分页页面 · 第 8/10 页