如何构建一个社交媒体排期工具

社交媒体排期工具中”排期”这部分，一个周末就能做完。一个队列，一个 worker，一个 cron 任务。这确实不难，也正因如此，估算总是错的。

真正昂贵的一切都在它的另一侧。

简单的那部分

一张带有排定时间的帖子表，一个会醒来查找到期帖子并发布它们的 worker。加上重试机制，就完成了。

如果你把这当成一个学习项目，或者只面向一个你自己掌控的平台，那可以不用往下读了。剩下的内容都是关于当涉及真实账号和多个平台时会发生什么。

你真正需要的数据模型

比大多数人想象的状态要多:

• draft(草稿)，已创建但尚未排队
• scheduled(已排期)，已排队等待某个时间点
• processing(处理中)，已发送至平台，结果未知
• published(已发布)，已确认
• failed(失败)，附带原因
• partial(部分成功)，已发布到部分目标，其余未成功

processing 之所以存在，是因为多个平台会先接受一条帖子，再异步发布。返回 200 并不等于发布成功，结果会在之后单独到达。没有这个状态，你的界面会声称发布成功，而这有时是错的。

partial 之所以存在，是因为一条帖子通常会面向多个平台。三个成功，一个失败。“已发布”和”失败”都不成立，把它强行归为其中任何一种，都会产生一个对用户撒谎的产品。

你还需要按目标单独设置状态行，而不是给整条帖子一个统一状态，因为失败是按平台发生的。

时区

存储时间点本身和 IANA 时区，而不是一个偏移量。

“每个工作日本地时间上午 9 点”在夏令时变化前后对应着不同的 UTC 时刻。只存储 UTC 在三月之前都相安无事，之后一切都会整体偏移一小时，而由此产生的 bug 报告会让人困惑，因为它一年中有一半时间是”正确”的。

平台层面的工作

估算正是在这里崩溃的。按平台计算:

一套独立的 OAuth 流程。 不同的授权范围、不同的令牌有效期、不同的授权界面。

一个独立的刷新任务。 这是最痛苦的部分。令牌会过期，刷新会悄无声息地失败，直到某条排定的帖子没有发出去，才会有人发现问题。你需要定时刷新、对刷新失败的监控、一个”连接已断开”状态，以及一套重新连接的流程。这比 OAuth 流程本身的工作量还要大。

一条独立的媒体处理流水线。 有的平台只需抓取一个 URL，有的需要可恢复的分块上传，有的对尺寸或编码有特定要求。你需要自己托管，甚至可能需要转码。

一套独立的速率限制，有自己的时间窗口，超限时也有自己的处理方式。

应用审核。 多个平台会将发布权限限制在一次涉及你的应用、隐私政策，有时还包括演示视频的审核之后。这是你无法掌控的日历时间，而且可能会被拒绝。

永无止境的变化。 API 版本会被弃用，字段会被重命名，权限会被收紧，一切都按平台自己的节奏进行。每一次都是计划外的工作，还带着一个不是你定的截止日期。

再乘以平台的数量。然后，永远持续地为此付出代价。

发布规则

除了投递本身，用户真正想要的是不发布会被拒绝的内容。这意味着要针对每个平台编码好:

• 字符限制
• 媒体数量、大小、格式、时长、宽高比
• 哪些帖子类型必须附带媒体
• 究竟存在哪些格式

并且要在创建时就进行校验，而不是等到发布时才校验，因为发布时才发现的失败，是用户在最佳时机已经过去之后才知道的失败。

什么情况下值得自己构建

• 你永久只面向一个平台发布
• 发布本身就是你的产品和差异化所在
• 你需要远超发布本身的深度功能，比如广告管理

什么情况下不该自己构建

如果发布只是你正在构建的另一个产品的一项功能，并且需要覆盖三个或更多平台。成本不在于构建本身，而在于维护，而维护的规模会随平台数量增长，你的团队却不会。

另一种选择

一次集成，把平台层面的变动交给别人去操心。

• 基础 URL: https://app.bulkpublish.com
• 鉴权方式: API key，若代表用户账号操作则使用 OAuth 2.1
• 接口范围: 59 个已文档化的端点
• 平台数量: 15
• 校验: 在创建时检查限制，而非在发布时才检查
• SDK: Node 和 Python，外加一个 Postman 集合和一个 MCP 服务器

简而言之

队列本身是一个周末的工作量。各种状态、时区处理，以及每个平台各一套的 OAuth 流程、刷新任务和媒体处理流水线，才是真正的项目所在，而平台层面的变动意味着这个项目永远不会完工。如果发布就是你的产品，或者你会永远只面向一个平台，那就自己构建。否则，一个你不需要维护的集成，比你需要维护的那个更值钱。