自媒体多平台同步发布，登录态掉了怎么办
一、先分清三种「没发出去」
内容点了提交，十几分钟过去，一个平台都没有新条目。多数人的第一反应是「工具坏了」，接着就是再提交一次、又提交一次。这一步就开始亏钱了——同一篇被人工重复提交，账号池里就会多出好几条队列记录，失败次数被推高，后面排查更难看清。
多平台分发里，「没发出去」至少是三件不同的事：
- 提交没被接口接收——请求本身没过校验，服务端压根没有这条内容；
- 进了队列但还没被消费——内容在排着，发布端还没取到；
- 被消费了但发不出去——发布端取到了，卡在各个平台自己的登录、验证或内容格式上。
三者的定位方法完全不同。判断所需的两个数据面，云梭发布都开放成了接口：账号池快照 POST /v1/pools/index，逐账号发布状态 POST /v1/distribution/status。第三方系统要接也可以直接读，不必等人工回复。
二、第一层：账号池快照，把 login_status 变成台账
/v1/pools/index 每个账号返回这些字段：pk、name、platform_name、login_status、publish_status、is_nurturing、last_used_time。
读这张表有一个必须知道的陷阱：login_status 不是实时探测的结果，它是上一次抓取或上一次发布留下的历史值。一个三天没发过内容的账号，状态显示「正常」，不代表现在还能用。矩阵号团队常见的错误就是「看到正常就以为没问题」，然后等到发布失败才发现登录态早就过期了。
login_status非「正常」→ 后面所有排查都不用做，先恢复登录态；login_status正常但last_used_time很旧 → 最危险的一档，它只是「还没被发现坏掉」；publish_status异常 → 平台侧对账号发布权限的判定，不在工具手里；is_nurturing为真 → 账号处于养号中，本周就不该给它排内容。
三、第二层：分发状态六档，只有两档能交给机器
内容提交后进入发布队列，发布端每 3 秒轮询取走一次任务。这里要澄清一个常见误解：队列里没有「计划发送时间」这种字段，入队即被消费，什么时候再试一次由退避时间决定，而不是由你设定的时刻决定。想把某篇内容压到某个时间点再发，靠的是你自己安排提交动作，不是产品替你等。
| status | 含义 | 谁负责 | 典型动作 |
|---|---|---|---|
| 0 | 待发布 | 队列 | 等，下一轮轮询会被取走 |
| 1 | 发布成功 | — | 记入台账 |
| 2 | 失败可重试（指数退避） | 机器 | 看 next_retry_time、failed_count，别手动重推 |
| 3 | 平台不支持该内容（终结） | 人 | 改内容形态，机器不会再试 |
| 4 | 触发验证码，需人工养号 | 人 | 本人处理验证，机器只能退避 |
| -1 | 数据异常 | 人 | 核对账号是否还存在、内容是否完整 |
只有 2 和 4 会自己退避重试。3 是终结态——机器不会替你把手里的内容改成那个平台收得下的样子；-1 通常指向数据本身缺失，重复提交一万次结果一样。
四、第三层：按 remark 分流，别把登录失效当网络故障
每条状态记录附带 remark，一句话说明卡在哪。实测里最常见的一句是「账号多次登录失败,等待用户更新账号」，对应的正是 status=2 的指数退避。这一句就说明：问题不在网络，也不在内容，而在登录态。
- 登录类：回到本地插件重新抓一次登录态。这是只有账号本人能做的动作，工具不会、也不该替你登录；
- 验证类：
status=4，平台要求人工验证，需要养号，机器只能退避； - 不支持类：
status=3，先查内容形态。分发链路对图片的判定走文件魔数，正文里的图必须是公网可直接下载的 URL；把带本地路径、或需要额外鉴权才能取到的图片链接塞进正文，到平台编辑器那一步就会被丢掉； - 数据类：
status=-1，核对账号与内容本身。
再看 failed_count：它是这条记录累计失败的次数。退避中的任务不是「失败品」，failed_count 到 5 次以上才值得人立刻介入，之前交给状态机即可。
五、恢复动作：为什么必须回到本地插件
云梭发布的登录态来源是本地插件从你机器上的 Chrome 抓出来的浏览器状态（cookie、本地存储等），抓上来之后存在服务端供发布端复用。由此有三个必须提前知道的现实：
- 插件目前只有 Windows 版本，并且要求本机装有 Chrome。这是真实门槛，不是可选项。多平台账号本来就在不同设备、不同登录习惯下运行的团队，要把这一条写进交接 SOP。
- 这些动作会让已抓到的登录态作废：在平台后台改密码、在别的浏览器或别的设备登录导致旧会话被踢、清理浏览器数据、平台自身强制下线、长期不用导致会话过期。表现就是第四节那句
remark。 - 恢复只能由本人在原环境重新抓一次，抓完再让队列里的退避任务自己重试。不要在恢复之前反复重新提交同一篇内容。
六、复发控制：一张登录态台账，五个字段
掉线本身不可怕，可怕的是每次掉线都是被动发现。把 /v1/pools/index 的返回落成一张周更台账，是矩阵号团队成本最低的做法。
| 字段 | 来源 | 建议阈值 | 阈值触发后的动作 |
|---|---|---|---|
| platform_name | pools/index | — | 分组维度，按平台排责任人 |
| name | pools/index | — | 账号标识，别只写编号 |
| login_status | pools/index | 非「正常」 | 当天在原环境重抓登录态 |
| last_used_time | pools/index | 距今 > 7 天 | 不等失败，主动重抓一次 |
| is_nurturing | pools/index | 为真 | 本周不给它排内容 |
配套巡检节奏（人做的事，不是系统替你做）：每天固定拉一次全量 pools/index，把异常项列进当日清单；每次批量提交后 30 分钟，对本次内容拉一次 distribution/status，只看 status=3/-1 和 failed_count>=5。平台数量口径是 14 个已接入平台 + 自定义站点通道，自定义通道是给客户自己站点用的，不拿它发对外推广内容。
七、算清成本：失效期间到底花了多少钱
计费口径（以服务端实际配置为准，1 元 = 10000 积分）：发布 850 积分/篇/平台，微信公众号与自定义站点通道五折。
- 发满 14 个可用平台：13 × 850 + 425 = 11475 积分 ≈ 1.15 元/篇；
- 注册赠送 10000 积分 ≈ 单平台 11 篇发布，够把整条工作流完整验证一遍。
两个实操结论：
- 一次全平台提交的成本不到 1.2 元，「怕浪费积分所以先只发三个平台」是伪命题；真正浪费的是发现异常后人工反复重新提交同一篇，把同一条内容在队列里堆成好几份。
- 退避重试期间是否重复扣费，接口口径里没有明确，需要自己实测确认（需补充实测数据）。在拿到实测结果前，预算按「一次提交 = 一份成本」估算是安全的。
八、这套流程不解决什么
写清楚边界，比许诺更多有用：
- 它不解决平台规则的临时变化。平台改了上传要求，工具侧不会自动知道；
- 它不替代人工验证。
status=4必须账号本人处理； - 它不替你改稿。
status=3是内容形态问题，要改的是内容不是配置； - 它没有排期能力。队列里只有失败退避时间，没有「计划发送时间」，所以「压到某个时间点再发」这件事在你的手上，不在产品里。
九、三分钟自检清单
下次「提交后没动静」，按这五步走，不要先重推：
- 拉
/v1/pools/index，列出login_status非正常，以及last_used_time超过 7 天的账号； - 对未完成的这篇拉
/v1/distribution/status，把记录分成四堆：0/1不用管、2/4交给退避、3改内容形态、-1查数据； - 登录类账号：在原 Windows + Chrome 环境用插件重抓一次登录态；
- 把
failed_count已经到 5 的账号单独列出来优先处理； - 台账更新「最近巡检日」和「下次巡检日」，让下一次发现是主动的。
云梭发布支持 14 个已接入平台与自定义站点通道的一稿分发，登录态由本地插件抓取后在服务端复用；上面这套排查只依赖两个开放接口的字段，任何团队都可以直接照抄进自己的运维手册。
