Express 在beforeRemote中，我可以使用res.send还是必须使用next（）？

TL；博士 假设客户机响应是以其他方式管理的，在beforeRemote中不调用next（）有哪些潜在问题/缺点

嗨

我在ModelBeforeRemote钩子中有一个基本验证函数，如果某些条件满足/不满足，它需要向客户端返回拒绝

我在早期的路由截取中使用res.send，它工作得很好，而在beforemote中使用res.send似乎也能工作。但我担心的是，文档非常清楚地指出，必须调用“next”，这意味着我无法手动恢复发送

我在前面的路线上是怎么做的

res.statusCode = 401;
return res.send("Access denied");

我是如何安全行事的

err = new Error("Access Denied");
err.status = 401;
delete err.stack;
return next(err);

我更喜欢第一种方法，因为我不必花“时间”抛出错误并在回调之前删除stacktrace（其他地方需要，因此无法全局删除）。在我看来，res.send似乎更干净，但这可能是一种误解？

---

最后，我不确定在“环回上下文”（ctx）中不结束远程发送是否有任何长期缺点。res.send是“只是”Express。

第二种方法更灵活。它允许您在发送回复之前执行一些操作。例如，您可能希望记录所有被拒绝的请求。或者，无论错误发生在何处，都可以重定向到主页

---

使用

next（err）

只需添加一些中间件即可，而使用第一种方法很可能需要在许多地方重复代码。或者，为了最终避免这种情况，写一些东西来做

下一步

让您能够做的事情。

正确。以“正确”的方式传递next将允许一些额外的处理，其中are res.send将结束链。但在这种情况下，这正是我想要的，这是一个基本的拒绝/要求，我不认为除了拒绝客户端之外还有什么需要做的。所以问题的核心仍然是：在BeforeRemote中不调用next（）有什么潜在的问题/缺点我想说的是，在您的情况下没有任何问题，您只是提前结束了请求/响应周期。然而，可能有一个缺点。因为你没有打电话给下一个，我很确定你将无法正确地调试你的服务器使用强大的远程。我可以接受这个答案，并同意这将至少防止环回调试，因为你结束它的范围之外，所以它会看到远程暂停。我仍然担心的是，除了调试不起作用之外，还有更多的问题，因为您通过返回Express res.send而不是Loopback next（），有效地杀死了中间件链。您的服务器使用的所有中间件都列在server/middleware.json中（默认为scaffolding）。我相信它们是按照文件中定义的顺序执行的（以确认）。知道了这一点，您至少可以准确地识别出哪些中间件被您的早期响应所短路。但环回应用程序的其他部分可能会受到影响，我不知道。也许性能分析也会受到影响