列表页忽然冒出两条完全相同的记录，统计页的汇总值比真实业务量高出一截，导出文件里同一笔数据反复出现。这类现象在软件维护中很常见，用户第一反应通常是数据库出了故障，但根因往往散落在数据来源、服务端处理和前端调用三个环节。接口返回重复数据不仅影响页面观感，还会干扰业务判断，例如把同一条记录当成两笔独立业务，进而导致库存、金额或用户数量的统计出现偏差。
先核对数据来源
第一步要确认上游查询是否缺少唯一标识。部分查询只按名称或时间筛选，没有用主键或业务编号做约束，结果集自然可能包含重复行。接着看多表关联是否发生膨胀，一对多关系如果没有先聚合就直接连接，主表一条记录会被放大成多条。最后检查分页参数是否错位，页码和每页条数在传递过程中被重复计算，也可能让同一批数据在不同页里再次出现。核对方法很简单：把接口背后的原始查询单独执行一遍，观察结果集是否已经重复。
再核对服务端处理
缓存拼接是常见诱因。比如先查缓存再查数据库，两段结果合并时没有按唯一键去重。重试机制也会带来重复，请求超时后自动重发，如果服务端没有做幂等控制，同一操作可能被写入两次。消息重复消费同样值得注意，队列在确认机制不完善时可能把同一条消息投递多次。排查顺序建议先看日志中同一请求是否出现多次落库记录，再检查缓存与数据库的合并逻辑，最后确认消息消费端是否有去重表或唯一约束。
最后核对前端渲染与调用方式
重复请求是最直接的原因。页面初始化时多个组件同时触发同一接口，返回结果被追加到同一列表。组件重复挂载也会造成类似效果，比如路由切换后旧组件未销毁，新组件又发起一次请求。分页数据追加逻辑如果缺少去重判断，滚动加载时同一页数据可能被重复合并。核对方法是打开浏览器网络面板，观察同一接口是否被调用多次，再检查列表合并时是否按唯一标识过滤。
一份可执行的核对清单
在软件维护中，把去重逻辑写清楚、可验证，需要一份可执行的核对清单。先确认每条记录是否有稳定的唯一键，数据库层面是否有唯一约束。再检查写操作是否具备幂等设计，重复提交不会产生第二条记录。然后通过日志比对，确认同一业务编号在入库、缓存和返回结果中出现的次数是否一致。最后做回归验证，用重复请求、重复消息和分页边界三种场景分别测试，观察接口返回是否始终唯一。it数运在软件维护服务中通常会把这类去重规则整理成文档，方便后续排查和交接。去重不是简单加一个 distinct，而是从数据源头到前端展示的完整链路核对，只有每一层都确认清楚，接口返回的数据才能真正可信。
