我们在应用程序中使用快速渲染，因此应用程序所需的所有数据都随应用程序本身一起发送。我们没有使用任何 Meteor.subscribe 调用，因为 minimongo 是由快速渲染填充的。
渲染后，我们运行 Meteor.disconnect()
在将来的某个时候，我们希望重新连接以调用特定方法，但是当我们重新连接时，minimongo 会被清除。
我们如何防止流星在重新连接时清除minimongo中的所有文档？
我怀疑实际上是快速渲染导致了您的问题。 检查流星文档以获取Meteor.disconnect()...
调用此方法以断开与服务器的连接并停止所有实时数据更新。当客户端断开连接时，它不会接收集合的更新，方法调用将排队，直到重新建立连接，并且热代码推送将被禁用。
致电 Meteor.reconnect 以重新建立连接并恢复数据传输。
这可用于在不需要实时更新时节省移动设备上的电池电量。
这意味着您的客户端数据永远不会被删除，否则您无法在重新连接时"恢复数据传输"。这也意味着他们这种方法的主要预期用例之一(例如，"在不需要实时更新时用于节省移动设备上的电池")实际上不起作用。
为了绝对确定，我检查了流星源以查看断开连接时会发生什么，它所做的只是将连接状态 var 设置为 false，清除连接和心跳计时器，并取消任何挂起的流星方法调用。
同样，Meteor.reconnect()简单地将连接状态 var 设置回 true，重新建立连接和侦听计时器，重新建立任何订阅(以便可以获取新数据......此操作不会删除客户端数据)，并调用任何排队的 meteor 方法调用。
在阅读了更多关于渲染工作速度的信息后，我了解到为了使其实际工作，我做了很多黑客工作。 跳到我面前的主要黑客是">假就绪"黑客，它欺骗客户端在实际订阅准备就绪之前认为订阅已经准备就绪(因为数据是在初始页面加载时发送到客户端的)。
由于您的应用程序中没有订阅，并且Meteor.reconnect()不会导致您的页面重新加载，我想知道客户端是否从未执行任何操作，因为它永远不会收到另一条ready消息。 或者也许是因为 Meteor 不知道任何订阅(因为快速渲染绕过 meteor 传输数据)，因此会清除客户端 minimongo 缓存，以便在启动新订阅时处于良好状态。 或者，快速渲染可能还有其他阻碍
。长话短说，根据查看文档、来源以及我离线测试流星应用程序的经验，我很确定Meteor.disconnect()和Meteor.reconnet()对您的客户 minimongo 数据没有影响。
我可以Meteor.reconnect()不会删除数据，因为我在生产中有一个流星应用程序，如果它检测到它已失去连接(例如计算机脱机、网络中断等)，它会继续调用Meteor.reconnect()。
希望这个冗长的答案可以帮助您跟踪应用程序的情况。
我尝试了Meteor.disconnect()并Meteor.reconnect()，但Minimongo DB没有被清除。 我使用以下方法确认了它：
a) 米尼蒙戈探险家：https://chrome.google.com/webstore/detail/meteor-minimongo-explorer/bpbalpgdnkieljogofnfjmgcnjcaiheg
b) 一个帮助程序，用于返回消息，如果在重新连接
期间的某个时间点我的集合将有零条记录。
虽然你是对的，但订阅中的所有数据都是在重新连接后从服务器发送到客户端的(不过让本地数据库执行同步操作)。 发生这种情况是因为 Meteor 服务器将重新连接视为全新的连接。 似乎在未来(不确定)Meteor将部署真正的重新连接，如他们的文档中所述：
当前当客户端重新连接到服务器时(例如在之后 暂时失去互联网连接)，它将获得新的 每次连接。onConnection 回调将再次调用， 并且新连接将具有新的连接 ID。
将来，当客户端重新连接完全实现时， 从客户端重新连接将重新连接到同一连接 服务器：不会为此调用onConnection回调 再次连接，连接仍将具有相同的连接 连接 ID。
来源： https://docs.meteor.com/api/connections.html