我现在有一个网站，它可以很好地使用Express，并且我有一堆路由器。我也在使用mongoDB，因此我可以使用req.user.username访问用户的用户名。
现在，我想进行聊天，而不必为整个服务器实现套接字。我只是不需要套接字在不需要时运行，而只需要在具有聊天的页面上运行。
我当前的想法就是这样：每当用户提出" getchat"请求时，我都会将聊天作为JSON对象发送。然后，在初始聊天渲染之后，我使用户称为" waitchat"请求。当其他人提出发布消息以发送消息时，我要么要解决。在" waitchat"中介绍聊天或获得waitchat res。有一个无尽的循环。
现在，我想进行聊天，而不必为整个服务器实现套接字。
不，你不能那样做。您的服务器实际上不知道您的一个网页何时可能会尝试连接到聊天服务器。您需要一直在听。
此外，看来您对聆听传入socket.io连接的含义有误解，因为没有连接的侦听服务器无需做任何事情，而无需花费任何费用。因此，"始终运行"一无所有。实际上，启动服务器，停止服务器，稍后再启动等等要花费更多的花费，而不是让它听。再加上您的措辞"不必为我的整个服务器实现套接字"，听起来您认为只有一个侦听socket.io服务器有些重量级。这根本不是一个重量级的概念。
此外，让您的socket.io服务器始终聆听绝对没有缺点。如果要通过以前设置的cookie或其他某些AUTH方法来验证传入的socket.io连接，则可以实现身份验证，以便只有授权的用户可以连接。
我不太遵循您与Waitchat和Getchat所说的内容。聊天背后的想法是，Usera可以发送一条消息，该消息将传递给UserB。USERA如何工作的概念是向服务器发送消息，然后服务器将其传递给Userb。
Usera显然很容易将消息发送给服务器。可以做任何多种方法。问题是服务器如何将消息传递给UserB。我想您知道，服务器不能直接与Userb联系。这样做的方法是：
- 用户b定期轮询服务器要求新的东西
- 用户B使用"长轮询"，这也是轮询，但是服务器可以在一段时间内保留投票请求，然后在有一些数据或时间返回时返回，然后客户必须再次进行轮询
- 用户b使持久的websocket或socket.io连接到服务器，然后服务器可以随时通过该连接将数据发送给客户端。
websocket或socket.io连接是迄今为止最有效的，实际上，整个概念是发明并添加到浏览器中的，因为两个投票方案不是很有效或可扩展。