用户点击提交后，页面显示“提交成功”，但运营人员进入后台却发现没有新增任何记录。这类情况很容易引发争议：前端认为接口返回正常，后端表示没有收到请求，业务方则只看到数据凭空消失。要减少反复沟通，关键在于按固定顺序排查，先判断问题出在哪一层，再决定修改哪里。
第一步，先区分三种“成功”。页面提示成功，可能只是前端脚本自行弹出的提示；也可能是接口返回了成功状态码，但业务数据并未真正写入；还可能是已经写入，却被事务回滚或后续流程覆盖。这三种情况对应的排查方向完全不同，不能一开始就直接查数据库。
第二步，核对前端提交动作。打开浏览器开发者工具，观察点击提交后是否真的发出了请求。常见情况有三种：按钮被重复绑定事件，第一次提交后状态未锁定，第二次请求被拦截；提交后页面立即跳转，请求尚未完成就被中断；表单校验通过，但提交函数中存在提前返回。逐一确认请求数量、请求地址和请求方法，可以排除相当一部分“假成功”。
第三步，核对接口返回与状态码。重点查看响应体中的业务状态字段，而不是只看HTTP状态码。有些接口无论业务成败都返回200，前端如果只判断网络层成功，就会把失败当作成功提示。同时检查请求超时设置：超时后前端若未做失败处理，也可能停留在成功提示上。错误处理逻辑应将业务失败和网络失败分开呈现。
第四步，核对服务端日志与入库记录。确认请求是否到达服务端、参数是否完整、写入语句是否执行。如果使用了事务，要检查后续步骤是否抛出异常导致整体回滚；如果走了消息队列，要确认消息是否被消费。日志中的请求时间、参数摘要和返回结果应能对应上，否则说明请求根本没有到达这一层。
第五步，核对数据库与缓存一致性。查询条件是否带有默认筛选、时间范围是否写错、字段长度是否被截断、必填字段是否被默认值覆盖，都可能造成“写进去了但查不到”。如果列表页读取的是缓存，还要确认缓存刷新延迟。用主键直接查询一次原始表，往往能快速分辨是写入问题还是查询问题。
实际排查时，可以按照“前端请求、接口响应、服务端日志、数据库记录、缓存与查询”的顺序逐层收敛，每层留下截图或日志片段，复测时用同一条测试数据走完整流程，确认提示、接口、入库三处一致。it数运在系统测试环节强调先定位再修改，避免在原因不明时反复改动代码，把问题越搅越乱。
最后建议保留一份简单的记录模板：提交时间、请求地址、响应状态、服务端日志编号、数据库主键、复测结果。涉及生产环境的查询和修改，应以实际系统文档和专业人员意见为准，先做只读核对，再决定是否动手。
