一对一聊天app开发中消息定时发送权限设置的那些事儿

做一对一聊天app开发有些年头了，踩过不少坑，其中消息定时发送这个功能看起来简单，但真正做起来的时候才发现里面的门道比想象的要深。今天就想跟正在做这个功能或者准备做的朋友聊聊，关于定时发送权限设置的一些实际经验和思考。

说白了，消息定时发送就是让用户可以提前写好消息，选择一个将来的时间点，让系统到点自动发出去。这个功能在日常生活里挺实用的，比如说半夜想到要祝朋友生日祝福，直接写好设定早上8点发送，既不会打扰自己休息，也不会错过时间。还有那种工作场景下，明明下班后才构思好的重要消息，完全可以设定在第二天早上9点对方刚上班的时候发送，显得既专业又体贴。

不过呢，这个功能要做得好用，权限设置这块才是真正考验功力的地方。

为什么权限设置这么重要

你可能会想，消息定时发送不就是加个定时器的事情吗？搞那么复杂干什么？说实话，我刚开始也是这么想的，结果上线后就出问题了。

首先是成本问题。定时发送意味着系统需要在后台维护大量的定时任务，每一条定时消息都需要占用一定的计算和存储资源。如果不加限制地让用户随便发，那服务器压力可不是开玩笑的。特别是那些用户量比较大的产品，光是维护这些定时任务的资源消耗就很可观。

其次是用户体验的考量。听起来有点反直觉是吧？但仔细想想，如果一个用户一口气设置了500条定时消息发往不同的联系人，这对其他用户来说其实是种负担。收消息的人可能短时间内收到大量推送，体验会很差。而且这种行为还可能被滥用，变成骚扰工具。

还有就是风控的需求。定时发送的消息在审核上比实时发送要麻烦一些，毕竟是提前设定好的内容，如果涉及敏感信息或者违规内容，事后追溯起来也需要相应的机制支撑。

基于这些考虑，权限设置就不是可有可无的东西了，而是整个功能的基础设施。

不同用户版本的权限差异

在设计权限体系的时候，我们通常会考虑把用户分层处理。这里说点实际的做法，不一定是最优解，但至少是经过验证可行的方案。

这个表格里的数值不是随便定的，都是根据实际用户行为数据调整出来的。普通用户那边设置20条其实是留有余量的，统计显示90%以上的普通用户日均使用量在5条以下。会员用户提升到100条，是考虑到有些用户确实有比较多重要联系人需要维护，提前准备一些节假日的祝福消息之类的。

企业版那边不限量是因为场景不一样，企业用户可能需要批量发送通知类消息，比如会议提醒、活动通知等等，这个和個人用户的使用场景有本质区别。

时间维度的权限控制

除了数量限制，时间维度也是权限控制的重要部分。这里说的时间维度主要包含两个方面：最长可以提前多少时间设定发送，以及定时消息的有效期是多久。

最长提前时间这个参数看着简单，但设置起来要考虑挺多因素的。时间设置得太短，功能价值就大打折扣；设置得太长，又会带来一些问题。比如用户提前三个月设置了一条消息，结果到发送的时候这个对话早就被删了，或者对方早就把用户删除了好友关系，这种消息发出去其实是没有意义的，还会造成系统资源的浪费。

我们现在的做法是动态调整这个时间上限的。根据用户等级不同，设置不同的上限，同时在消息即将发送前的一个时间点（比如提前24小时）进行一个预检查，看看这个对话是否还存在，双方的好友关系是否正常，如果有问题就提前通知用户处理或者直接取消发送。

另外还有一个容易被忽视的点：时区问题。用户可能在不同的时区之间切换，提前设定好的消息如果还是按照原来的时区发送，就可能出现误差。这方面最好在用户设置定时消息的时候明确显示发送时间，并且让用户选择是否需要根据收件人所在时区自动调整。

内容审核与权限的关系

定时发送的消息在内容安全这块需要特别注意。因为是提前设定好的内容，如果在发送的时候才进行审核，一旦发现问题就晚了——消息已经到达对方设备了。所以比较合理的做法是在用户设置定时消息的时候就进行实时审核，审核通过后才进入待发送队列。

但这里就有权限平衡的问题了。实时审核意味着用户设置消息后不能马上离开，需要等待审核结果。如果每条消息都要审核，体验上会比较差。特别是对于一些高信任度的用户，反复审核其实是没有必要的。

解决方案就是引入分级审核权限。普通用户的消息设置时立即审核，高信任度用户（比如活跃时间长、没有违规记录的老用户）可以采用抽检方式，VIP用户可以申请白名单机制，大幅减少审核流程。

对于内容审核这块，我们当时在集成声网的即时通讯解决方案时，他们提供了一套比较完善的审核机制，包括敏感词过滤、AI内容检测、人工复审等多个环节，可以灵活配置不同用户等级的审核策略，这一点对我们帮助挺大的。

特殊场景的权限处理

除了常规的一对一聊天场景外，还有一些特殊场景需要特别考虑权限设置。

比如群发消息的情况。很多用户会问，为什么定时发送功能限制只能一对一，不能群发？这里面其实是有考虑的。群发定时消息被滥用的风险比一对一高很多，一不小心就可能变成广告轰炸工具。所以一般产品要么完全不支持群发定时消息，要么就设定非常严格的权限门槛，只有特定用户等级或者经过认证的企业用户才能使用。

还有跨平台消息的权限处理。如果你的产品支持多端登录，那定时消息的设置和发送就需要协调好各端的权限。比如用户在手机上设置了一条定时消息，在发送前又登录了电脑端，把这条消息删掉了，那系统应该以哪个为准？这种情况需要明确各端的优先级逻辑，并且做好状态同步。

另外就是账号状态变化的情况。用户被封号了、会员到期了、主动注销账号了，这些情况下定时消息如何处理？一般建议是在账号状态变化时，对所有定时消息进行状态复核，不符合继续发送条件的要及时处理掉，同时通知用户。

权限设置的技术实现思路

说了这么多权限设计的思路，再聊聊技术实现层面应该怎么考虑。倒不是要讲具体代码，而是说几个关键的技术决策点。

首先是定时任务的存储方式。一种方案是用数据库存储所有的定时消息，然后用一个或多个定时任务轮询数据库找出到点的消息进行发送。这种方案实现简单，但扩展性一般。另外一种方案是使用优先级队列，把定时消息按照发送时间排序，专门的调度器只需要关注队首的消息，时间到了就处理，处理完再看下一个。这种方案性能更好，但实现复杂度也高一些。

然后是权限校验的时机。最好是用户设置消息的时候就进行权限校验，提示用户还剩多少额度能用，而不是等到发送的时候才发现没有权限了。前者用户体验好太多。

还有就是权限的实时更新问题。用户的会员状态、等级变化应该实时反映到权限里。比如一个普通用户刚刚升级为会员，那他应该立即获得更高的定时消息额度，而不是要等下次登录。

在消息可靠投递方面，需要考虑的场景还挺多的。网络不稳定怎么办？发送失败怎么办？对方离线怎么办？这些问题都需要有对应的重试策略和补偿机制。特别是定时消息，因为发送时间已经是确定的了，错过最佳发送窗口的消息如何处理，是丢弃还是立即发送又或者是延迟发送，都需要产品层面给出明确的规则。

我个人的一些经验教训

做这个功能的过程中，我们团队也犯过一些错误，这里分享出来，希望能给到大家一些参考。

最早期的时候，我们没有做数量限制，结果遇上了一个用户设置了3000多条定时消息，直接把数据库的一个查询接口拖慢了。后来紧急加了限制，但这种救火的事情最好还是提前预防。

还有一次，时区处理出了问题，有个用户在出国旅行期间设置了定时消息，结果按照国内时间发送了，但收件人在国外，收到消息的时间是凌晨3点，体验非常差。这个问题让我们意识到时区处理真的不是个小问题。

另外就是推送通知的配合。定时消息发送成功后，需要给用户发一个推送通知把这个消息送达。但推送本身也有自己的通道和配额限制，如果同一时间有大量定时消息需要推送，推送通道也可能成为瓶颈。这个需要和消息推送的策略配合好，比如错峰推送或者合并推送。

写在最后

消息定时发送这个功能看似简单，但要做到好用、可靠、不出岔子，需要考虑的点还是很多的。权限设置更是其中的核心环节，直接关系到功能的可用性、系统的稳定性以及用户体验的好坏。

不同产品面对的用户群体不一样，使用场景也不一样，所以权限策略没有标准答案，最重要的是根据自己的实际情况去设计、调整、验证。希望这篇内容能给正在做这个功能的同行一些启发，少走一些我们走过的弯路。

如果有什么问题或者不同的想法，欢迎一起交流讨论。