删除列表项成功后重新调用GET接口获取列表是否为不良实践？

这其实没有绝对的「最佳实践」，得看你的应用场景和核心需求来选择，我给你拆解两种方案的适用情况、优缺点：

方案一：DELETE请求成功后调用GET接口刷新列表 #

• 适用场景：
  • 多人协作的系统（比如团队任务管理、共享文档列表），需要确保客户端状态和服务器全局最新状态一致；
  • 服务器端删除操作会触发复杂的业务逻辑（比如关联资源清理、统计数据更新、权限变更等），本地无法精准模拟这些变更；
  • 对数据一致性要求极高的场景（比如金融类应用），容不得本地状态和服务器出现偏差。
• 优势：能100%保证客户端展示的是服务器的真实状态，避免因本地更新遗漏服务器端的隐性变更，或者其他用户同时修改数据导致的不一致。
• 小劣势：多一次网络请求，会增加少量的UI更新延迟，但在现代网络环境下影响通常很小，也可以通过缓存策略（比如设置合理的缓存头）来优化重复请求的开销。

方案二：DELETE请求成功后仅本地更新应用状态，不调用GET接口 #

• 适用场景：
  • 单人使用的应用（比如个人笔记、待办清单），不存在多用户并发修改的情况；
  • 服务器端删除逻辑非常简单（仅删除目标条目，无任何关联数据变更），本地可以精准同步服务器的状态变化。
• 优势：UI反馈更快，无需等待GET请求的响应，用户体验更流畅，同时减少了服务器的请求负载。
• 注意事项：一定要确保DELETE请求确实返回成功状态后再执行本地更新，不能提前做乐观更新（除非你已经做好了请求失败后的回滚逻辑）。另外，如果后续有其他入口能进入列表页面，最好在页面加载时仍调用GET接口拉取最新数据，避免长期的状态不一致。

关于你提到的乐观更新 #

你说得没错，乐观更新的核心是提升用户体验的即时性，而不是减少服务器调用——它是先更新本地UI，再发送请求，请求失败时再回滚UI。这和上面两种“请求成功后如何同步状态”的方案是不同层面的问题，你可以把乐观更新和任意一种方案结合（比如乐观更新UI后，DELETE成功再选择是否调用GET刷新）。

内容的提问来源于stack exchange，提问作者Charles Watson