目前我遇到的场景是这样的。

以下所有功能都是基于云开发

场景：收集用户推送信息，然后有推送需求再统一推送。（先收集并储存用户的推送请求到一个集合A，并设置为false，推送成功后设置为true，未成功的用户依旧为false，这样来判断用户推送的成功率）

坑来了！

坑1:云函数只能读取100（官方已更新至1000）条数据，也就是你一次只能推送给1000个人，数据需求量大，比如你有1万用户，难道重复10次？

解决方案：我们可以先读取所有数据的集合，然后再循环推送。

参考链接：https://developers.weixin.qq.com/miniprogram/dev/wxcloud/reference-sdk-api/database/collection/Collection.get.html

坑2: 接坑1的需求，由于云函数的运行内存为256M，当我们数据量较大的时候，云函数就处理不过来，会报错如下。

解决方案：这个时候我们就需要开启本地调试了，开启本地调试，再通过开发者工具，来启动推送命令，这样，就很少会报错了，即使报错，也会先推送完很多任务。

坑3: 接坑1，坑2的需求，我们都将推送用户储存到了A集合，如果在推送的过程中由于时间差或者某些不特定因素的关系，当a介绍到了消息，z还没有由于某些因素没有推送到，需要重新推送，但此时a已经又重新打开了小程序并将推送需求储存到了集合A，这样一来，我们是不是又给A重复推送了一次。

解决方案：我们可以在推送前，添加一个新的集合B，在云函数修改，把下一轮要接收订阅消息的用户储存到B，这样一来，是不是A和B就都互不影响了。

再说的通俗易懂点，就是我们先将一部分人带到一个A会议室，等要公布新消息的时候，我们把门关上了，不让别人再进来，把后面到来的人带到B会议室，依次类推。

这样做的好处就是用户不会收到2次相同的消息，同时还能判断推送的成功率。而且在云函数后端就能自主完成，不需要重新发布代码进行审核！

如果大佬们有更好的意见，可以留言共同探讨。

低端程序员一枚，我只是将我的一个处理经验分享给大家，不喜勿喷。