Express.js中更新/删除前验证资源存在性的实践与性能疑问

1. 更新或删除前验证资源存在是否属于良好实践？ #

得结合业务需求和错误处理策略来看，没有绝对的标准答案：

• 如果你的API需要明确给前端返回「资源不存在」的错误（比如HTTP 404状态码），让用户清晰知道操作失败的具体原因，那提前做存在性验证很有必要——毕竟直接执行更新/删除后，虽然能通过modifiedCount或deletedCount判断是否有实际操作，但前端没法区分是「资源本身不存在」还是「资源存在但未满足更新条件」。
• 如果业务逻辑对错误原因不敏感，只要操作最终结果符合预期就行（比如不管资源本来就不存在还是成功删除，都返回成功响应），那完全可以跳过前置检查，直接调用MongoDB的updateOne/deleteOne方法，通过返回结果里的计数判断操作是否生效。
• 要是涉及权限验证（比如只能删除自己创建的资源），前置检查可以把「资源存在性+权限校验」合并成一次查询，比先查存在再查权限更高效，这种场景下前置查询反而是更优的实践。

2. 额外的数据库访问会带来哪些潜在性能影响？ #

多一次DB请求确实会产生性能损耗，主要集中在这几个方面：

• 网络往返开销：每多一次DB请求，就多了一次应用服务器与MongoDB之间的网络传输，在分布式环境（比如云数据库）中，这个延迟会被放大，高并发场景下可能成为性能瓶颈。
• 数据库资源占用：两次查询会占用更多的数据库连接、CPU和内存资源，如果查询没有配置合适的索引，两次全表扫描的开销会非常大。
• 竞态风险：如果在前置检查和实际操作的间隙，资源被其他请求删除或修改，会出现逻辑错误——比如你刚检查完资源存在，执行删除时它已经被删了，这种情况需要依赖原子操作来规避。

不过如果你的查询有合适的索引（比如用_id或唯一键查询），单次查询的开销其实极小，大部分业务场景下这种性能损耗完全可以接受，和清晰的错误反馈相比性价比很高。

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