X（Twitter）API 发帖限制 2026：每天能发多少条推文

作者：Sorsa 编辑部

更新于 2026 年 7 月 11 日：补上已确认的未认证账号上限（每天 50 条原创帖子和 200 条回复，据 X 限制页面，自 2026 年 5 月中旬起），移除未公布的 Premium 每日数字，并把节奏限制改述为 X 有文档记载的半小时子限制。

核心要点： X API 写入接口允许每用户每 15 分钟 100 条帖子，每应用每 24 小时 1 万条。除此之外，X 账号还有平台级上限，会把 API 和手动发帖合并计数：自 2026 年 5 月起，未认证账号每天 50 条原创帖子、200 条回复。真正先拦住自动化的，是这个账号上限。

2026 年通过 X API 发帖，撞上的不是一道限制，而是三道各自独立、分别执行的上限。API 接口有自己的按应用和按用户速率限制。发帖所用的 X 账号有平台级每日上限，无论帖子来自脚本还是手机 App。在按量付费下，每条创建的帖子都要计费，同一账号的读取侧还压着 200 万次帖子读取的硬性上限。三者中任何一个都会返回错误，这就是为什么“明明离速率限制还远着呢”是自动化 X 的开发者最常见、也最困惑的抱怨之一。

本指南按当前数字覆盖这三层，全部对照 X 自己的文档核实过。我们开发并运营 Sorsa API，这是一个用于读取公开 X 数据的 Twitter/X API 替代方案，所以发帖本身不是我们的赛道：写操作属于官方 API，下面这些就是你在官方侧要面对的限制。我们能帮上忙的是发帖工作流的另一半，也就是读取部分：确认帖子已上线、拉取互动数据、发布后监测提及。相关章节会逐一标出。这里的发帖数字，是官方 X API 现在给你的。

最后核实：2026 年 7 月 6 日，对照 X 官方的速率限制和账号限制文档。

目录

• X API 发帖限制如何运作
• 通过 X API 每天能发多少推文？
• 回复、删除和私信的速率限制
• 点赞、关注和转帖呢？
• 2026 年 X API 免费版还能发帖吗？
• 拦住大多数自动化的半小时节奏
• 撞上发帖限制时会发生什么
• 如何规模化发帖而不触发限制
• 常见问题

X API 发帖限制如何运作 {#how-x-api-posting-limits-work}

2026 年，X 在三个各自独立的层面上执行发帖限制：写入接口的 API 速率限制、X 账号本身的每日上限，以及按量付费对每条帖子的计量。请求可能在任何一层失败，而每一层给出的信号都不一样。

第一层是 API 速率限制。写入接口（POST /2/tweets）允许每用户每 15 分钟 100 条帖子，每应用每 24 小时 1 万条。这是从你第一次请求开始计算的滚动窗口，不是从整点开始的固定窗口，越界任何一个都返回 HTTP 429。

第二层是账号上限。每个 X 账号都受平台级发帖限制约束，这些限制横跨网页端、移动端和 API 一并生效。X 的限制文档写得很明确：这些每日上限会把“来自所有设备，包括网页、移动端、电话和 API”的动作合并计数。所以自动发的帖子和手动敲的帖子，从同一个每日预算里扣。这一层是大多数指南漏掉的，也通常正是真正拦住机器人的那一层。

第三层是计费。X 在 2026 年 2 月转向按量付费之后，每条创建的帖子都要花钱（按 2026 年 4 月 20 日重新定价，纯文字帖子 $0.015，含 URL 的帖子 $0.20），账号在读取侧还压着每月 200 万次帖子读取的独立硬性上限。你完全可能舒舒服服待在发帖速率限制之内，却在读取上被拦住；也可能眼看一个链接密集的发布工作流迅速变贵。完整的按动作成本，包括 URL 溢价和去重窗口，见 2026 年 X API 价格详解。

实用结论：API 速率限制很少是发帖的瓶颈，账号上限几乎总是。

通过 X API 每天能发多少推文？ {#how-many-tweets-can-you-post-per-day-via-the-x-api}

单看 API，一个已认证用户每 15 分钟最多可发 100 条推文，一个应用横跨所有用户每 24 小时最多 1 万条。但这些帖子所属的 X 账号在平台级另有上限，而这个账号上限低于 API 上限，通常就是拦住自动化的那一道。

这两层对单个账号是这样叠加的：

自 2026 年 5 月中旬起，X 的限制页面把未认证账号封顶在每天 50 条原创帖子和 200 条回复，比长期沿用的 2,400 条大幅缩水。这个每日预算还被拆成半小时的子限制，具体间隔数字 X 没有公布。普遍反馈是转帖和引用帖也计入这 50 条，但 X 没有正面确认；帮助页面有些地方还写着旧的 2,400，各类指南上互相矛盾的数字就是这么来的。已认证（Premium）账号不受这些公布的上限约束，X 也没给出对应数字，所以在 Premium 账号上，真正起作用的就是上面那些 API 写入限制。

坑在于围绕 API 限制来设计。开发者看到“每 15 分钟 100 条帖子”（折合每用户每天近 9,600 条），就照这个数字搭系统。结果机器人早早就卡住了，因为先起约束的是账号级上限和它的半小时节奏。对跑自动化的未认证账号来说，每天 50 条帖子才是真正的上限，不是那个 API 窗口。

这种分层行为在读取侧同样存在：15 分钟窗口，加上“按应用”与“按用户”两个池，是大多数采集管道出现 429 的原因。那些读取限制在配套的 X API 速率限制参考里逐接口讲清楚了。

回复、删除和私信的速率限制 {#rate-limits-for-replies-deletes-and-direct-messages}

在 X API 上，发顶层推文、发回复、删除推文和发私信，各自适用不同的写入限制。回复和原创帖子共用 POST /2/tweets 接口和同一份限制，但删除和私信更严，受各自的窗口约束。

删除是跑清理任务时最容易被低估的一项。按每用户每 15 分钟 50 次删除算，清掉 1,000 条旧推文大约要五个小时实际耗时，跨二十个窗口铺开，而且没有批量删除接口可以提速。能清空大时间线的工具，靠的是把等待状态设计进流程，而不是更快地重试。

回复在 API 限制之上还有自己的账号级上限。对未认证账号，X 的限制页面把回复上限设为每天 200 条，与 50 条原创帖子的预算分开计算。所以一个自动回复提及的机器人，可能在原创帖子预算一点没动的情况下，先把回复额度用光。

私信是刻意做慢的。每用户每 15 分钟 15 条，每 24 小时 1,440 条，平台级还有一个被广泛引用的约每账号每天 500 条私信的上限。自动化消息很快就会撞墙，这是刻意设计的。这些写操作都没有只读替代路径：比如读取私信历史同样被限在每 15 分钟 15 次请求，所以私信密集的工作流两头都受约束。

点赞、关注和转帖呢？ {#what-about-likes-follows-and-reposts}

关注账号、点赞帖子和引用发帖，在 2026 年换了访问层级。自 2026 年 4 月 20 日起，X 把这些互动写操作移出自助按量付费，改为仅限 Enterprise。也就是说，用程序点赞、关注或引用发帖的自动化，现在需要 Enterprise 合同，标准开发者应用不够用了。发帖和私信仍留在按量付费上。

在那次变动之前，这些动作公布的 API 限制本来就很紧：点赞和关注约为每用户每 15 分钟 50 次，另加 24 小时上限，转帖节奏类似。这些数字现在对自助用户已无意义，因为接口整体关进了 Enterprise 权限之后。

账号级方面，关注仍与帖子分开设限。普遍反馈是未认证账号约每天 400 次关注，Premium 账号约 1,000 次。X 还会盯关注、取关的循环模式，即便每日数字没越界也可能触发限制。点赞没有公开记载的账号限制，但激进的自动点赞很容易触发行为层面的限流。

如果你的工作流依赖程序化的互动写入，官方 API 的 Enterprise 层是唯一合规路径，写操作没有只读替代方案。只读 API 覆盖的是测量那一侧：与其去点赞或关注，不如读取谁互动过。拉取转发或回复了某条活动推文的账号属于读操作，由转发用户和回复者查询这类接口处理，这样采集数据完全不涉及任何用户账号。

2026 年 X API 免费版还能发帖吗？ {#does-the-x-api-free-tier-let-you-post-in-2026}

2026 年，X API 对新开发者没有通用的免费版。X 在 2026 年 2 月按量付费上线时停掉了独立的免费版，新账号在发出第一条推文之前必须先买额度。2026 年 X API 到底免不免费对新注册只有一个答案：不免费。

如果你手上还有遗留的免费版应用，发帖额度从设计上就极少。遗留免费版只能写，按 24 小时窗口计量，文档记载的 POST /2/tweets 额度是整个应用共享、每 24 小时 17 次请求。有些资料引用的是更高的月度数字，那对应更旧的 v1.1 路径，各类指南里“17 还是 50”的困惑就是这么来的。无论按哪种算，它都只是个用来测试发帖集成的摆设，从来不适合大批量运行，而且完全不提供帖子读取权限。

所以免费版从来就不支持大规模发帖，对新开发者更是已经不存在了。如果你真正要测的是读取 X 数据而不是发帖，第三方访问才是实用的免费路径。注册即送 100 次免费请求：无需绑卡，永不过期，覆盖全部 40 个读取接口，与付费套餐同样按请求计费。走批量接口的话，这些额度在付费前最多可覆盖 1 万条推文或 2 万份用户资料。这足够跑一次真实负载来验证读取集成，比多数服务商发放的小额试用额度宽裕得多。

拦住大多数自动化的半小时节奏 {#the-semi-hourly-pacing-that-stops-most-automations}

真正拦住最多发帖自动化的，并不是那个显眼的每日数字。X 把每个账号的每日发帖预算再拆成半小时的子限制，在每日上限之上、于账号级执行，独立于 API 速率限制，而且不公布间隔数字。直播发推的人、话题串工具和回复机器人经常触发这道节奏限制，有时候每日上限还没露面就先卡住了。

这么容易触发，是因为预算又小又共享。未认证账号每天 50 条原创帖子、200 条回复，转帖和引用帖普遍反馈也从同一个池里扣，而且全都要摊进半小时的子区间。集中回复大批提及的机器人，或者在紧密循环里逐条发出的话题串，可能不到一分钟就耗尽一个区间的额度，然后卡住等重置。

在这之上还叠着第二道更安静的拦阻：重复检测。X 会拒绝在大约 24 到 48 小时内发布的文本相同或高度相似的帖子，返回错误码 187。反复推送同一条消息的自动化，在常青内容发布或多账号运营里很常见，即便离任何速率限制都还远，也会踩到这一条。改法很简单，改一个字符或一个标点就能通过重复检查，但这一步必须内建进工作流。

控制写入节奏的实用规则：把帖子铺开到一整天，别对着每日上限集中爆发。回复和话题串按 10 到 15 条一批排队，批次之间留出刻意的间隔，反复使用的文案要做变体。只盯着每日数字来设计，正是自动化跑到一半卡住的原因。

撞上发帖限制时会发生什么 {#what-happens-when-you-hit-a-posting-limit}

超出 API 速率限制时，X 返回带错误码 88 的 HTTP 429：

{
  "errors": [{
    "code": 88,
    "message": "Rate limit exceeded"
  }]
}

响应里仍然带着速率限制响应头，那才是关键部分。x-rate-limit-reset 是窗口重新打开的 Unix 时间戳，所以写入工作进程不必盲目地睡一个固定间隔。账号级上限越界和重复内容被拒的表现都不一样。账号上限通常返回 403 或发帖限制通知，不是 429；重复内容返回错误 187。所以发帖器要能区分这三种情况，而不是把每次失败都当成速率限制。

写入路径上一个能感知重置时间的重试，大致长这样：

import time
import requests

def post_tweet_with_retry(text, headers, max_retries=3):
    url = "https://api.x.com/2/tweets"
    for attempt in range(max_retries):
        response = requests.post(url, headers=headers, json={"text": text})

        if response.status_code != 429:
            return response

        reset = int(response.headers.get("x-rate-limit-reset", 0))
        wait_seconds = max(reset - int(time.time()), 1)
        print(f"Rate limited. Waiting {wait_seconds}s until the window resets.")
        time.sleep(wait_seconds + 1)  # +1 秒缓冲

    raise Exception("Rate limit retries exhausted")

有两点要留意。第一，不要在 429 之后立刻重试，紧密的重试循环会在仅应用认证下把其他接口的剩余预算一起烧掉。第二，每次写入前检查 x-rate-limit-remaining，掉到个位数就主动放慢，别等硬停。在批量发帖或删除循环里，一个没处理的 429 可能在代码察觉之前就级联成一连串失败。

如何规模化发帖而不触发限制 {#how-to-post-at-scale-without-tripping-limits}

想在 X API 上拿到真实的发帖量，关键不在每日上限，而在于 30 分钟窗口和账号上限之下的节奏。下面这些动作才真正改变结果。

1. 按半小时子限制来控节奏，别只盯每日上限。 X 把每日预算切成半小时区间，间隔数字未公布，所以回复和话题串要按 10 到 15 条一组、带间隔分批发，不要集中爆发。这道节奏几乎是每个自动化最先撞上的约束。

2. 高频发布用已认证（Premium）账号。 50 条帖子和 200 条回复的每日上限只适用于未认证账号；X 的限制页面豁免已认证账号，也不公布它们的数字，所以真正的约束回到 API 写入限制。

3. 反复使用的文案要做变体，避开重复检测。 错误 187 会拒绝 24 到 48 小时内高度相似的帖子。常青内容或多账号发布时，轮换措辞，或者加一个唯一元素。

4. 成本模型里记得算上 URL 溢价。 带任何链接的帖子按 $0.20 计费，纯文字帖子只要 $0.015，成本差 13 倍以上，链接密集的发布工作流很快就会烧到真金白银。这次涨价背后的成本账，见我们的 X API 为何变得如此昂贵。

5. 写入队列和读取队列分开。 发帖和读取从不同的限制里扣，在按量付费下还从不同的上限里扣，200 万次月度帖子读取上限与写入预算完全无关。两条队列各自独立，读取积压才不会堵住定时帖子，反之亦然。

最后这一点，正是大多数生产级发帖方案最终会拆到两家服务商的原因，也直接引出下面的实用模式。

发帖对比读取：哪个 API 干哪个活

大多数真实的 X 工作流两件事都要做，而这两半在 2026 年属于不同的基础设施。向 X 写入（发帖、回复、发私信）是第一方动作，必须在官方 API 上跑，受上面那些限制约束，并使用用户认证令牌。而大量读取 X 数据，比如验证帖子已发布、拉取互动、监测提及、采集时间线，正是官方按资源定价和逐接口窗口既贵又别扭的地方。这一半交给按请求计费的只读 API 更合适。

• 自动发帖、回复、私信： 官方 X API，按量付费或 Enterprise。写操作没有合规的只读替代方案。
• 程序化点赞、关注、引用发帖： 官方 X API 的 Enterprise 层，因为这些在 2026 年 4 月 20 日离开了自助渠道。
• 确认帖子已上线、拉取互动、监测提及、批量读取： 以读取为主的替代方案，例如 Sorsa，所有套餐统一 20 次/秒，没有逐接口窗口，读取在批量基准上每 1,000 条推文 $0.02 起。

这条分界值得直说：如果你需要向 X 写入，那是官方 API 的地盘，这里没有任何东西能改变这一点。但同一个工作流里读密集的那一半，交给按请求计费、价格可预测的只读 API，就能摆脱 15 分钟窗口和按资源计费。只把读取迁过去是常见的第一步，从官方 API 迁移的路径介绍了怎么在完全不碰写入侧的前提下完成这件事。

实战：不断被发帖限制卡住的机构

某社媒机构约十几人，替客户跑定时发帖，总是撞上他们解释不了的发帖限制。他们的调度器是围绕 API 那个“每 15 分钟 100 条”的数字设计的，但客户账号老是在活动进行到一半时被锁。原因出在账号层。未认证的客户账号远在 API 限制起作用之前，就先撞上了平台每日上限和半小时节奏，转帖还悄悄计入同一个预算。

写入侧的修法是运营层面的，不是迁移：把高频账号升到 Premium，按半小时子限制控制节奏，文案做变体，避免再触发错误 187。写入路径留在官方 API 上，本来也该留在那里。真正迁走的是读密集的报表层：确认帖子已上线，为客户仪表盘拉取逐条互动。这部分此前一直在悄悄消耗 200 万次月度读取额度。改成按请求计费后，这部分读取最多可比官方按资源模式便宜 50 倍，报表账单降到每月两三百美元。节奏一改好，发帖限制也跟着解除了。

常见问题 {#faq}

2026 年用 X API 每天能发多少推文？

X API 写入接口允许每用户每 15 分钟 100 条帖子，每应用每 24 小时 1 万条。真正起约束的通常是账号上限。自 2026 年 5 月起，未认证账号每天最多 50 条原创帖子和 200 条回复，并按半小时子限制摊开；已认证（Premium）账号不受这些公布的上限约束。

删除推文的 X API 速率限制是多少？

通过 DELETE /2/tweets/:id 删除推文，限制是每用户每 15 分钟 50 次请求，而且没有批量删除接口。按这个节奏，清掉 1,000 条推文大约要五小时实际耗时，跨二十个窗口铺开。大规模清理任务靠的是在批次之间安排等待，而不是更快地重试，因为这些停顿本身就是 API 的设计。

能通过 X API 发带链接的推文吗，要花多少钱？

能，但按 2026 年 4 月 20 日重新定价，含 URL 的帖子在按量付费下每条 $0.20，纯文字帖子只要 $0.015，成本差 13 倍以上。大批量自动发布邮件订阅链接、博文或推广 URL 的工作流会很快变贵。所以在上线链接密集的发帖自动化之前，成本模型里必须算上这笔 URL 溢价。

2026 年 X API 免费版允许发帖吗？

对新开发者来说，通用的免费版已经不存在。X 在 2026 年 2 月按量付费上线时停掉了它，新账号发帖前必须先买额度。遗留免费版只能写，整个应用每 24 小时只允许约 17 条帖子，且完全没有读取权限。如果你要测的是读取，Sorsa API 注册即送 100 次免费请求，无需绑卡，覆盖全部 40 个接口。

明明没超发帖速率限制，为什么还是收到 429？

429 说明某个 API 窗口被超出了，但发帖失败往往来自另一层。账号级每日上限（未认证账号每天 50 条原创帖子和 200 条回复）把 API 和手动发帖合并计数，通常在 API 限制之前就起约束，一般返回 403 或限制通知。文本高度相似的重复内容返回错误 187。要区分这三种情况，别把每次失败都当成速率限制。

开发者怎样在不撞限制的前提下获得高读取吞吐？

发帖留在官方 API 上，读密集型的工作迁到按请求计费的替代方案，绕开逐接口窗口。以 Sorsa API 为例，所有套餐统一 20 次/秒，提供全部 40 个读取接口，批量基准上每 1,000 条推文 $0.02 起，套餐 $49/月起。在读取规模上，这比官方按资源定价最多可便宜 50 倍。

如何开始

如果你的发帖工作流也要读 X 数据，比如确认帖子已上线、为报表拉取互动、发布后监测提及，那么读取这一侧正是官方逐接口窗口和按资源计费最伤人的地方，交给按请求计费的只读 API 更合适。感受差异最快的办法是自己跑几次调用：在线试用工具 Playground 在浏览器里直接调用真实接口，无需密钥也无需注册，可以先看清响应结构。准备好开工时，Sorsa API 快速上手用单个密钥几分钟内完成认证。创建账号，领取 100 次免费请求（无需绑卡，永不过期，覆盖全部 40 个接口，最多可覆盖 1 万条推文或 2 万份用户资料）；付费套餐 $49/月起，批量基准上每 1,000 条推文 $0.02 起，所有套餐统一 20 次/秒，没有逐接口窗口要管。向 X 写入仍然留在官方 API，读取这一半不必如此。

审校：Keksich（Sorsa 创始人，X API 研究者）

本指南是怎么写成的：API 写入和删除限制、429 响应体和接口路径，直接读自 X 官方的速率限制表；账号级发帖上限读自 X 的限制文档。两者都在 2026 年 7 月 11 日重新核查过，因为这些数字改动时往往不打招呼，而且 X 自己的帮助页面有些地方仍写着旧的 2,400，各处互相矛盾的每日上限就是这么流传开的；本文给出的 50 条帖子和 200 条回复取自当前的限制页面。发帖节奏和重复检测的做法、429 恢复代码，以及三层框架，来自我们运营只读 Twitter/X API 的实际经验，以及我们团队经手的读取管道迁移，包括上面那个匿名机构案例（细节已做合并处理，去除了任何可识别信息）。定价数字总结自我们单独的 X API 定价内容。我们是谁、怎么联系我们，见关于 Sorsa。本文没有任何编造的统计数据、来源或客户成果。