REST开发中存在性校验时机判定：标记通知已读场景疑问

一、什么时候需要做存在性校验？ #

判断是否需要存在性校验，核心看这几个维度：

• 操作的前提是资源必须存在：比如修改、删除某个资源，或者创建关联资源（比如给文章加评论），如果目标资源不存在，后续操作完全没有意义，必须提前校验并返回明确错误。
• 需要给客户端清晰的错误反馈：符合REST规范的接口应该用状态码明确告知结果，比如资源不存在返回404，权限不足返回403，而不是返回空数据让客户端自己猜。
• 业务规则要求前置校验：像注册时校验用户名/邮箱是否已存在，这是业务层面的强制规则（不允许重复账号），属于必须的前置校验。

二、你的通知标记代码是否需要校验存在性？ #

需要。目前你的代码里，findByIdAndUpdate如果找不到匹配的文档（比如通知已被删除，或者该通知不属于当前用户），会返回null，此时你直接返回200和null，客户端拿到后无法区分「操作成功但通知本来就是已读」还是「通知不存在/无权限」，不符合接口的健壮性要求。

优化后的代码可以这样：

export const markNotificationAsRead = asyncErrorHandler(async (req, res, next) => {
    const { notificationId } = req.params;

    const updatedNotification = await Notification.findByIdAndUpdate(
        { _id: notificationId, recipient: req.user._id },
        { read: true },
        { new: true }
    );

    if (!updatedNotification) {
        return res.status(404).json({ message: "通知不存在或无权限操作" });
    }

    res.status(200).json(updatedNotification);
});

三、「用户看到通知后，标记前通知被删除」的场景是否合理？ #

完全合理，这是实际业务中常见的并发场景：

• 用户打开页面加载了通知列表，此时通知还在数据库；
• 同时系统触发了删除逻辑（比如通知过期自动清理、管理员手动删除、发送方撤回通知）；
• 用户点击标记已读时，数据库里已经没有这条通知了。

这种场景必须考虑到，否则接口会返回不符合预期的结果，影响用户体验。

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