你的工单已关闭。但用户仍然无法支付。

你的后端返回了 200 状态码。 移动端 App 显示错误。 用户点击了三次“支付”。 账户被扣了三次款。只有一个订单成功。用户的余额现在变少了。 你的日志显示零失败。

每个工程师都完成了自己的工作，但没有人解决问题。

团队的失败往往不是因为代码写得烂，而是因为他们在做错误的工作。你可能交付了一个运行完美的系统，却创造了糟糕的用户体验。

初级工程师以“工单”为思维模式： 分配工单。 编写代码。 测试通过。 PR 合并。 关闭工单。

随着你的成长，这种思维方式会成为一种隐患。一个只会关闭工单的工程师是有用的，但一个会问“这真的解决了业务问题吗？”的工程师是不可或缺的。

以支付流程为例。 后端工程师构建了一个接口 (endpoint)。它处理扣款并返回正确的状态码。100% 测试覆盖率。工单关闭。 移动端工程师构建了界面。它调用接口并显示响应。UI 流畅。工单关闭。

没人负责的问题：如果在扣款后、移动端收到确认前网络断开了，会发生什么？

后端显示成功。移动端显示失败。用户重试后被扣了两次款。

修复方案不仅仅是后端或移动端的修复。它需要幂等键 (idempotency keys)。移动端必须为每次尝试生成一个唯一的键。后端必须使用该键来确保重试永远不会产生重复扣款。

只有当工程师们开始讨论网络中断时的用户体验时，这种解决方案才会出现。

硬件领域也是如此。 硬件工程师交付固件。 移动端工程师交付 App。 后端工程师交付 API。 每个部分都正常工作。每个测试都通过了。

但用户按下按钮后，灯在 11 秒后才亮起。延迟存在于组件之间的缝隙中。没有一个工程师负责端到端的响应速度。

真正的可靠性是系统的属性，而不是单个组件的属性。

要解决这个问题，你必须改变工作方式：

你的职位头衔描述的是你的技能，而非你责任的边界。

如果你是后端工程师，你负责的是用户能否可靠地完成支付。如果你是移动端工程师，你负责的是用户的信任感。

完成工单只是底线，对用户最终结果负责才是天花板。

来源：https://dev.to/walosha/your-ticket-was-closed-the-user-still-couldnt-pay-14di