公众号登录态能活多久？我们盯着 156 个账号，答案是 2.7 天

先说结论，省你时间：

微信公众号的网页登录态，从你扫码那一刻起算，大约 2.7 天后必然失效。中间用得再勤，也不会延长。

这个数字是我们盯着 156 个账号、横跨 31 个平台跑了 15 个月之后，从一次次断更里量出来的。

我们是怎么发现的

一开始我们和大多数人的想法一样：登录态嘛，用着用着就续上了，只要天天发东西，应该不会掉。

结果是隔三差五就有账号“哑火”——后台显示任务发出去了，实际上一条都没发成。等发现的时候，往往已经断更两天。

一个账号出问题可以说是意外。当同样的事在不同账号上反复出现，而且间隔时间惊人地接近，就不是意外了。

我们把每个账号的“最后一次扫码时间”和“第一次任务失败时间”拉出来对齐，发现两者的间隔非常稳定：大约 65 小时，也就是 2.7 天左右。

这才是真正坑人的地方。

按一般 Web 应用的习惯，会话往往是“滑动过期”——你每操作一次，有效期就往后顺延一次。所以直觉上，一个天天在发文章的账号，登录态应该比一个放着不动的账号活得久。

实际不是这样。 我们观察到的是固定过期：从扫码那一刻开始倒计时，中间发了多少篇、操作了多少次，都不影响那个时间点的到来。

这个差别听起来只是技术细节，落到运营上却完全是两回事：

如果是滑动过期，那“保持活跃”就是有效的运维策略；
既然是固定过期，“保持活跃”给你的只是虚假的安全感。你越是天天在用、越是每次都看到发布成功，就越不会想到去检查登录态——直到它在某个你没留意的时刻突然断掉。

单个账号，2.7 天不算什么问题。你每两天扫一次码，甚至设个闹钟就解决了。

但内容矩阵不是这么回事。

假设你管着 20 个公众号，每个账号的扫码时间都不一样——有的是周一下午登的，有的是周三早上登的。于是这 20 个 2.7 天的倒计时各自独立、错落分布。结果就是：几乎每天都有账号在掉线，而你永远不知道今天轮到哪几个。

更糟的是失败的表现形式。登录态失效之后，任务往往不是“报错”，而是看起来正常地失败——队列照常消费、状态照常流转，只是内容没有真的发出去。等你从阅读量异常里察觉不对，两天已经过去了。

账号越多，这个问题不是线性变难，而是变得不可能靠人盯。

三件事，按重要性排：

第一，把登录态当成有保质期的东西来管，而不是出问题再说。

既然过期时间是固定的、可预测的，那它就不该以“故障”的形式被发现。我们给每个账号记录扫码时刻，倒推出失效时间，在到期之前就主动提醒，弹二维码出来扫一下就续上了。把一件本来会变成事故的事，变成了一个日程提醒。

第二，不相信“发布成功”这四个字。

接口返回成功，不等于内容真的出现在了线上。所以我们在发完之后会真的去线上把那篇抓回来看——它在不在、标题对不对、正文的图有没有丢。登录态过期导致的静默失败，很多就是在这一步被抓出来的。

第三，账号和 IP 要对得上。

这一条和登录态有关但常被忽略：同平台的多个账号如果共用一个出口 IP，很容易被判定为批量注册的营销号。一旦触发风控，掉的就不只是登录态了。所以我们让不同账号强制走不同出口。

会。平台随时可能调整策略，2.7 天不是写在文档里的承诺，只是我们在这段时间里量出来的稳定值。

所以真正该带走的不是“2.7 天”这个具体数字，而是这三点：

我们把这些做法做进了自己每天在用的工具里——闻响矩阵。它管着我们自己那 156 个账号，登录态到期前会主动喊人，发完会去线上回查那一篇是不是真的在。

这些规矩没有一条是设计出来的，全都是被坑出来的。