记一次bug修复过程

个人建议，究竟有谁会看，以个人位置，到底能推进到哪一层
可行性，可能性

问题：
用户的数据丢失了。觉得是修改操做 有bug，但查看了后端接口和前端校验，都没有发现问题。
可是input数据没有日志【日志级别是debug】，不能自证清白。
而且一些没有办法轻易证实的猜想也有：是否是并发问题，一个insert操做操做刚完成，另外一个请求上来了，把这个新insert的数据删除了。查了api网关，真找到有两个触发时间比较接近的两个请求 。。。
纠结中：这个简单的逻辑，还出问题，以为很不爽，也不服气。

tips:这种状况下，可使用这种话术----”我先看一下“   若是直接说”这么接口这么简单，怎么可能有问题“ ---------------提出bug的人，可能以为本身提出的判断或事实，被否认了。
            


解决办法：
是修改接口被误用，在别的场景中被调用了

 

 

背景： 需求描述

有一个 一个页面添加多个项的操做，
而且支持对多个项 进行 修改， 删除几个原有的，再新增几个

方案1：对已有id的更新，对没有id的进行insert ，还有对 删除项 进行删除-----这个貌似是最好的。略有复杂
删除，若是使用逻辑删除，则在 新增的记录 时，要不要和已有删除项的数据进行对比呢，若是已存在，则更新老的标识位，让其可见便可------ 问题：怎么断定是一条相同的记录呢。特别是字段比较多的场景

方案1：先删再增
是逻辑删，仍是物理删除。

能够逻辑删，但要定时清表。对于操做频繁的表，数据量会愈来愈多

问题：
一个接口有变动，但接口没有按 单一职责 进行设计，调用散落在了不一样的业务点。 
思考--对一个表不一样字段的修改，可能会用于不一样的场景。 看到有很多地方是处处使用这个接口，这就形成 参数校验会散落在各个场景
一个对表的修改操做