我目前正在根据此页面上提供的规范实施 DDP 客户端： https ://github.com/meteor/meteor/blob/master/packages/livedata/DDP.md
我只是对称为“就绪”和“更新”的 2 种方法类型有疑问。
根据规范，让我们从“准备就绪”开始：
当一个或多个订阅完成发送其初始一批数据时，服务器将发送一条带有其 ID 的就绪消息。
这样做意味着我们可以从服务器获得多个“添加”消息，直到将整个集合完全传输到客户端。我们应该把它存储在一个临时的地方，然后等待“准备好的”信号量在公开之前？即在真正的收藏中？
关于远程过程调用的相同问题。我是否应该将结果存储在临时集合中，并且仅在收到“更新”消息后才返回（处理）结果？
这部分晦涩难懂
一旦服务器基于此过程调用完成向客户端发送所有相关数据消息，服务器应使用此方法的 ID 向客户端发送更新的消息。
“应该”，所以如果我确实依赖它但什么都没有，我会被卡住吗？
我们应该把它存储在一个临时的地方，然后等待“准备好的”信号量在公开之前？即在真正的收藏中？
标准 Meteor JavaScript 客户端使添加的文档在客户端集合中可用，因为它们来自服务器。因此，例如，如果集合正在网页上显示并且到目前为止 100 个文档中有 5 个已经到达，那么用户将能够看到这 5 个文档。
当订阅“就绪”消息到达时，客户端上的订阅被标记为“就绪”，如果客户端正在执行需要等待所有数据到达的操作，则可以使用该消息。
是否要在客户中等待所有数据到达后再将其公开取决于您...这取决于您对客户所做的事情以及您是否想在文件到达时显示文件。
“应该”，所以如果我确实依赖它但什么都没有，我会被卡住吗？
Meteor 服务器确实会发送“更新”消息，因此您可以依赖它。
关于远程过程调用的相同问题。我是否应该将结果存储在临时集合中，并且仅在收到“更新”消息后才返回（处理）结果？
进行方法调用有两种结果：方法返回的返回值（或错误）（“结果”消息），以及可能已被方法调用插入/更新/删除的文档（“更新”消息）。您想听哪一个取决于您：是否知道何时收到来自方法调用的所有文档更改很重要，或者您是否只想要方法返回值。
Meteor 客户端使用“更新”消息来执行“延迟补偿”：当客户端更改本地文档时，更改会立即应用于本地文档（并且更改将对用户可见）... on假设更改可能会被服务器接受。然后客户端发出一个请求更改的方法调用，并等待从服务器发送更新的文档（如果它们被接受，则可能包括更改，如果被拒绝，则可能包括更改）。当接收到“更新”消息时，本地更改被丢弃并被来自服务器的真实更新所取代。如果您没有在自己的客户端中进行延迟补偿，那么您可能不会关心“更新”消息。