部分客户端对网络请求的知识真的薄弱

从你的描述上来看就是后端没有把做法给讲明白，藏着掖着了，

这个第三方接口有问题，以前是后端做了超时重试，前端以为是个很小的改修，就是换个地址，工时估了 0.5 小时，结果你让他加超时，重试，工作量一下上来了，且不是一个简单的工作量

而且还得给前端埋了地雷，

前端请求如 axios ，大多数加了封装，好，我加了你说的超时重试，用户点击加入购物车，后端返回超时，我又发了下请求，用户刷新看见购物车两条数据， 懵了，你说这事怪谁？

加个请求重试和超时机制 跟你的标题有什么强关联吗？

@laved 还以为你说的是 http 之类的知识呢

接口要是没有幂等，重试了生成两条数据怎么办。
超时重试也不会解决转圈等待的问题啊，接口慢，客户端可不得就转圈等待。

针对“经常出现失败、一直转圈卡死的情况”，解决方案是“在网络请求加重试、超时机制” ？啊？啊？

最起码得排查下是第三方可用性还是啥问题。。

加重试是什么鸵鸟战术。

一般 app 反馈问题，我都让他卸载重装试试。

@maocat #1
@weixind #5 三方接口是公开的，自己看文档对接，怎么我后端能看懂，客户端不能看懂吗？
我可以告诉你苹果的接口，你可以骂他懒，但你改变不了什么。你去找苹果沟通吧

@SoulFlame #7 懒->烂

@yuyuf #4 此接口不存在幂等问题，不讨论。
我说的转圈等待描述的不够清楚，客户端 UI 表现是加载动画永远转圈，不会结束。

@maocat #1 另外补存在什么工时问题，我们公司制度没有这么复杂，测试只是要他想办法解决这个问题，都没有和他讨论工时问题。客户端直接回复就是解决不了

这不应该是现在就有的问题，一直以来都有问题缺少完整的异常处理机制，我也是做客户端的

网络请求加重试不是随便就能加的，得看业务是否合理，是否需要幂等，更合理的是要从源头排查为什么会失败或超时、超时机制就是另外一码事，我不相信连这个都没有

说个搞笑的:(真事)
我 boss:app 登录后,要记住密码。 就是重启后,不需要用户每次都输入密码。
然后前端:
真的记住密码了,每次进入登录页,发起登录获取 token,跳转到首页。

前端懂记住 token 的,跟他做了挺多项目。
显然他没转过弯,直接把 boss 的话一比一实现了。

一般都会设置 time-out

哈哈，那后端就不会在循环里写 rpc 了吗。说到底是人菜。没辙，AI 还会放大这个问题。给彩笔配上 ai 那只会进一步加快他拉屎的速度

国企吗？以前在某国企上班，那些开发真的是纯做一份工作而已，啥都不懂。

我觉得有的后端也没好到哪里去。问说接口通不通，说能 ping 通。我寻思 ping 和访问接口也没几毛钱关系。协议都不是一个协议。好多后端根本分不清大多数 API 应该怎么测试连通性。区分不了请求 API 报错大概是哪个层面的问题。

放宽心吧，放两年前我也会像 op 一样有点鄙视这种知识储备差+不学习
现在，我只想说，一份工作而已，太认真负责是消耗自己心力

大概率小公司，小平台