没用 swr 么？

问题一：接口相互依赖，重试，缓存，乐观更新，状态管理这类的场景让你们前端尝试下 Tanstack Query ， 有效减少扯皮的空间，专注业务。 问题二：前端项目改造下 HTTP 请求类方法就行，把 code===0 作为正确的结果返回，其它一律作为异常抛出 message 不就行了？严格来说应该优先判断 HTTP 的状态码，在辅以业务码判断，但不得不说能跑满 1G 带宽，这屎山代码还是有点实力的 https://i.imgur.com/agAJ0Rd.png

@realkaiway 对方是客户端，app ，安装在用户手机里的。几十万个设备，同时这样发请求，流量能不大么。我还是不建议了，他们好像不愿意改历史代码，只在自己的模块改东西。

@litchinn 我是接收方，nginx 接受能力比较强，后代的网管和服务就惨了，cpu100%，线程池和队列全满了，根本处理不过来。nginx 上全是 500 错误。对方是客户端，几十万台手机，循环产生 1g 的请求还是比较容易的，而且还是 post ，上报数据，请求体本来就大。

这不是日常吗？ 1.提 bug 单督促改呗，不行就 cc 双方领导，保证自己不粘锅就行了 2.基操基操，都是正常操作，你让他们改，他们会说他们也是调 xxx 接口转发 or 网关 xxx or 历史 xxxx ，反正就是改不了你凑合用吧，也就多写几个 if 而已，又不是不能用

@pulutom40 我只是想吐槽，cc 领导已经没啥用了。偶尔一次两次我也不会来吐槽，这么多年了经常这样。我领导也说，做好限流，别让自机的服务崩掉就行，不行加机器。。。乏了

@mystical cc 领导不是为了有用，而是为了甩锅，风险暴露出来让领导知道就行了，跨部门他不去沟通，出问题他背锅就行了

"例子：请求 A 返回数据 a ，请求 B 需要使用请求参数 a 请求，返回数据 b 。然后并发发送，A 发出去了，不等结果发送 B ，发现 a 参数没有，直接扔给我一个默认值。(乱七八糟什么都有可能，x ，y ，z ，喜洋洋、灰太狼)" 不太能理解这种场景为什么也要并发 如果请求 B 需要 A 的返回, 那么并发请求 A 和 B 性能上的好处只在于服务器处理完 A 请求且服务器收到 B 请求前的这个时间间隔吧? 能想到几种办法优化且更规范的. 那么 OP 是怎么应对的, 最后是什么情况好像没说诶.

@Dorathea 本意是吐槽，我完整的表述一下。不便说太细，有问题可以留言 场景：很多，比如启动预加载信息，进某个页面批量获取信息。批量调用是合理的也是正确的。 问题： 后续加入的新 api 有依赖关系，app 框架依然使用批量调用，这扫问题点 优化方案： 很多，举几个 1. 最简单的就是 app 不在批量线程里执行，等待 A 的数据拿到之后再请求 B 接口 2. 后端代理执行，前端请求 A 和 B ，B 不使用 A 的参数，后端代理客户端再请 A 一次， 3. 后端察觉的请求数据 不对，返回客户端参数异常，等客户端拿到 A 的接口再次重试（很糟糕的方案） 最后措施：方案 3 ，客户端依然批量执行，如果没取到，后端 api 报错，前端重试，直到成功 last 方案 1：其实说到最后，就是原有的批量执行方案不可修改。至于为啥不可修改我也不得而知。 方案 2：为啥后端不代理执行，因为两个机器中间隔了一个太平洋，又完全不是一个系统，考虑到用户各种隐私都需要上报太过笨重。话说归来，问题也不是从后端引发的。 方案 3：为啥选择重试呢？ 我也想问，可能这样开发量最小吧。3 楼我提出的问题就是这样产生的。 我做了那些事： 无非就是增加网管鲁棒性，限流，等等后端常用的技术方案 ps: 上面打错了 流量是 1000Mb 打错单位了。

不是，一直以为这种情况只会出现在我们这种用户几十个的内部系统哈哈哈哈哈