问一下这种情况是公司的 Java 在忽悠我不懂后端吗?

[excitedXXX]

1.公司测试提了个 BUG,一个 list 删除某 item 显示成功但没从 list 中移除.接着从 log 中发现删除的 code 返回是成功的,提示成功后再次请求 list 被删除的 item 仍然给我返回了.遂觉得是后端的原因,便把 BUG 指给了他.然后这货告诉我是因为主从库延迟的问题,需要删除成功后前端自己先去移除 list 中的 item.我就问问这种问题大家遇到过吗?都是怎么解决的
2.接着过了一段时间 list 接口偶现 code5000,提示 sql 有错.这货就说一定是你前端的问题啊,前端传的参数不对,后端 sql 当然就报错了,没办法气势没人家强,打印 log 发现参数没有问题,告诉这货这货也不吭声,也不知道改了没.事后一想,不对啊,偶现的 BUG 怎么可能会是参数的问题,我寻思着参数不对你也应该每个提示吧,直接崩了就不太好了吧.
.....类似的事情太多了,什么 int 无值给个 null,性别无默认值也给 null,为 null 的连这个字段都不传过来....
这是我不懂后端,还是技术壁垒没办法?

[amon]

一般调接口先用 postman 类的工具调通了再接入，所以如果 postman 类工具调用都有各种问题，把问题甩给后台就对了：）

[wupher]

是的，他在忽悠你。

这其实和前后端都没关系，没有想伤人的意思，但我真心觉得这个是智商问题。

问题 1：后端给予你的结果要保证逻辑严密性。哪怕是真有清 cache 等异步操作，后端也要保证给你的结果是准确有效的，要去除，也应该是后端去除。

问题 2：偶现不偶现和是否参数真没关系。后端可能完全把某个用户输入给拼接成 SQL 了，如果用户尝试注入或者输入某些含 SQL 关键字的乱码，就会造成异常。不过，的确如你所说，用户输入本来就不能信任。他要缺点德给你来个 SQL 注入都是有可能的。站在后端的角度，所有的前端调用都是不能信任的，参数必须经常验证和鉴权。

所以，综上所述，我觉得你的队友虽然甩锅是一方面原因，另一方面，你确实也应该自我提升一下。

当然，也可能是你在开贴骗分 ¯\_(ツ)_/¯

祝春节快乐

[xuanbg]

1、主从延时过高的话，是运维的锅，你找后端没用。
2、前端对 list 里面的 item 进行操作的同时，应该自己更新数据而非偷懒调接口刷新数据。一来体验不好，二来空耗流量。如果是新增 item，可以让接口返回 id，然后自己更新对象的 id 后插入到 list 里面。
3、接口爆炸的那个完全就是后端嘴硬罢了，SQL 错了就是代码写得不够安全。