记一次bug修复过程

我的建议，究竟有谁会看，以我的位置，到底能推动到哪一层
可行性，可能性

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

tips:这种情况下，可以使用这种话术----”我先看一下“   如果直接说”这么接口这么简单，怎么可能有问题“ ---------------提出bug的人，可能觉得自己提出的判断或事实，被否定了。

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

背景： 需求描述

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

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

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

可以逻辑删，但要定时清表。对于操作频繁的表，数据量会越来越多

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