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