矩阵号自动发布：难的是让几十条链路一直保持能发

账号托管靠的是登录态复用，而不是存账号密码。系统在恢复登录时会一次性灌回会话所需的三类存储（Cookie、本地存储、会话存储），并对没有过期时间的 Cookie 兜底续期 72 小时，避免发一次就得重新登录。

真正的差异在那个后台服务：每分钟巡检一次，把超过两小时没有被使用的账号挑出来，按最久未用的顺序，一轮最多起 3 次浏览器去复登确认。它解决的是矩阵号最常见的事故——某个号已经掉线两周，而你以为内容发出去了。

复登失败会被计数：连续失败 5 次的账号自动移出发布池，不再占用任务队列。你在账号列表里能直接看到哪些号需要人工点一次「更新」重新登录，而不是在一堆失败任务里反推是哪个号的问题。

另有一层每日零点执行的账号池状态重置，把当日维度的限制归零，避免昨天的额度用完影响今天的发布。

把 Cookie 传到服务器上直接发，最容易踩的坑是IP 与登录时不一致：你在家里登录的号，服务器从机房 IP 提交，平台看到的就是「异地登录」，几次之后要么要求验证，要么直接风控。

所以架构上做成了本地插件常驻 + 出口 IP 对齐：插件在你自己的机器上跑一个后台服务，登录与发布走同一条出口，IP 特征与真人操作一致。插件同时承担本机正向代理的角色。

连接方式上做了两条路：优先走点对点直连，条件不具备时自动切到中转出口，并在托盘上明确告诉你当前是哪一种。切换不影响发布，也不需要你处理——这条设计的目的就是让账号看起来始终是同一个人在同一个网络上操作。

矩阵发布的稳定性，一大半取决于操作痕迹是否像真实用户。这里做了几件具体的事：浏览器注入反检测脚本后再启动；每个动作步长有400 到 800 毫秒的随机延时；单个步骤超过 1 秒才追加这点抖动，避免无意义拖慢；富文本正文用剪贴板粘贴而不是逐键模拟输入——后者在多家平台的编辑器里会被识别，或者干脆丢内容。

单步操作有 25 秒的默认超时，卡住会明确失败而不是无限挂着。页面里那些「看着能点、点了出事」的诱饵节点在候选阶段就被排除，这是踩出来的规则，写不进需求文档。

还有一层刻意保守的选择：需要人类身份确认的环节一律不做。出现短信验证码、出现扫码要求，当次直接判失败转养号。任何号称能自动过验证的矩阵方案，风险都记在你的账号上，而不是记在工具上。