Twitter 趋势 API：2026 年获取热门话题

作者：Sorsa 编辑部

2026 年 7 月 8 日更新：加入了 100 次免费请求的起步额度、对照官方按量付费趋势费率刷新了当前的按请求定价，并重新确认了接口的默认结果数和那个常为空的推文计数字段。

要点： 要在 2026 年通过一个 API 获取 Twitter (X) 热门话题，发一个带 WOEID（一个地点的数字 Where On Earth IDentifier）的已认证 GET 请求。官方 X API 在付费层级上于 GET /2/trends/by/woeid/{woeid} 用一个 Bearer 令牌提供这个，覆盖全球约 470 个趋势地点。

Twitter 趋势 API 不必意味着 OAuth、一条应用审查队列，或一份五位数合同。替代性 Twitter/X API Sorsa API 通过一次用单个 API 密钥认证的 /trends 调用，返回同样基于 WOEID 的趋势。每个趋势回来时，已经配好一个即跑的搜索查询和一个直接 URL；计费按请求算：一次趋势拉取在 Pro 套餐（$199 换 10 万次请求）上花约 $0.002，对比官方 API 上约 $0.20，后者按每个 $0.010 读取同样的 20 个趋势。速率限制是所有套餐统一 20 次/秒，没有 15 分钟窗口。

热门话题是开放网络上少数几个实时信号之一，显示数百万人此刻在关注什么。营销团队用来给活动择时，新闻编辑室用来发现突发故事，量化席位则把它当作一个早期信号层。2026 年难的部分很少是用例，而是干净地把数据弄出来，因为官方路径比多数教程承认的更碎片化、更昂贵。

本指南覆盖今天实际可用的东西：基于 WOEID 的取回如何工作、官方 X API v2 趋势接口如何行事（包括其不足之处），以及如何用单个 API 密钥拉趋势。文中给出 Python、Node.js 和 curl 里的可用代码。多数现有教程仍引用已弃用的 v1.1 接口和 Tweepy 的 OAuth 1.0a 流程，那对趋势不再适用。

目录

1. 什么是 Twitter 趋势 API？
2. 2026 年通过代码获取 X 趋势的两种方式
3. WOEID 如何工作（以及为什么每次趋势调用都需要一个）
4. 用 Sorsa API 获取热门话题
5. WOEID 参考：主要国家和城市
6. 代码示例：Python、Node.js 和 curl
7. 把趋势与搜索结合以做更深分析
8. 官方 X 趋势接口的常见问题
9. 趋势数据的用例
10. 速率限制、缓存和最佳实践
11. 实战中：为一个新闻编辑室席位轮询趋势
12. 常见问题
13. 开始上手

什么是 Twitter 趋势 API？ {#what-is-the-twitter-trends-api}

Twitter 趋势 API 是一个 HTTP 接口，返回某个特定地理区域当前在 X（前身 Twitter）上趋势的话题。典型响应是某个地点约 20 到 50 个话题的排名列表，由平台每几分钟重新计算一次。这样访问到的趋势是按地点限定的、非个性化的。

这个区别要紧。X 网站上个性化的“为你的趋势”视图，混入你关注的账号和你的活动，且不通过任何 API 暴露。API 返回的则是 X 为某个区域计算的全平台、按地点限定的列表，这正是你想用于分析、监控和研究的。

列表每几分钟重新计算。对几乎每个工作负载，每 5 到 15 分钟轮询每个地点一次，就能在新趋势出现时立刻抓到，又不浪费请求。

2026 年通过代码获取 X 趋势的两种方式 {#two-ways-to-get-x-trends-through-code-in-2026}

2026 年通过代码取回 X 热门话题有两条实际路径。一是官方 X API v2 趋势接口，在付费层级上用一个 OAuth 2.0 Bearer 令牌认证。二是把同样基于 WOEID 的数据封装在单个 API 密钥之后的第三方 REST API。两者都返回按地点限定的趋势，区别在认证、定价，以及每个趋势对象包含什么。

选项 1：官方 X API v2 趋势接口

X 在 GET /2/trends/by/woeid/{woeid} 暴露其趋势接口，接受一个 WOEID 作为路径参数，返回一列趋势对象，每个携带一个 trend_name，以及一个你通过 trend.fields 参数请求的可选 tweet_count。完整参考在 X 的官方趋势文档里。

认证是一个 OAuth 2.0 Bearer 令牌，这意味着要注册一个开发者应用，并处在 X API 的一个付费层级上。2026 年对趋势没有免费访问，平台现在按资源对读取计费，所以每个返回的趋势都是一个单独计量的单位。要看那个定价如何工作的更广上下文，见我们的 2026 年 X API 定价拆解和官方 API 为何这么贵。

要从一个热门话题走到背后的实际帖子，你得自己构建搜索查询，并单独调用搜索接口。

选项 2：一个单密钥趋势接口

Sorsa 趋势接口围绕另一个优先项构建：让趋势数据在数据管道的下一步就可用。响应包含趋势名，加一个预建的搜索查询和一个直接 URL，所以你能直接接入更深的分析，无需写任何查询构造代码。

认证是 ApiKey 请求头里一个单个 API 密钥。没有 OAuth 流程、没有应用注册，也没有开发者审查。注册、复制一个密钥、发请求；头 100 次请求免费、无需绑卡。定价跨每个接口（包括趋势）都是按请求计费，所以一次趋势列表取回，和一次用户查找或一次搜索调用花费相同。

并排：官方 X API 趋势 vs Sorsa

下面是一份具体针对趋势取回的事实对比，每个选项的真实局限都如实陈述。

数字里透出的模式：在任何真实的轮询量上，按请求计费都比为每个单独趋势付费便宜得多。单个 API 密钥则免去了 OAuth 和应用审查开销。诚实的告诫：两个选项都不返回历史趋势，Sorsa 接口也不给每个趋势附一个推文量数字。接下来的各节展示如何用好两者，常见问题一节则覆盖官方 tweet_count 一开始为何不可靠。

WOEID 如何工作（以及为什么每次趋势调用都需要一个） {#how-woeid-works-and-why-every-trends-call-needs-one}

WOEID（Where On Earth IDentifier）是一个唯一标记某个地理地点的数字 ID。Twitter 在 2010 年前后为趋势采用了 WOEID，并沿用至今，所以每次趋势 API 调用，都要求你所要地点的一个 WOEID。有大约 470 个有效的趋势 WOEID，横跨全球、国家和城市级别。

几个例子让形状清晰：

• 1 是全球（全局趋势）
• 23424977 是美国
• 23424975 是英国
• 23424900 是墨西哥
• 2459115 是纽约市
• 44418 是伦敦

国家级 ID 覆盖整个国家，市镇级 ID 覆盖单个都会区。不是每个国家都有市镇级趋势；较小的市场往往只返回一个全国范围列表。你不必按区域用不同方式认证，也没有按区域的定价。只要你知道那个整数，就能取那个地点的趋势。

如何找到一个地点的 WOEID

对最常见的市场，用下面的参考表。对顶级市场之外的任何东西，一份完整的 X 支持趋势地点列表，作为 GitHub 上的公开 WOEID gist 维护，含所有有效条目。Sorsa API 不单独暴露一个“可用地点”接口，所以那个 gist 才是权威查找；如果一个地点不在其中，X 就不在 API 层级为那个地方发布趋势数据。

用 Sorsa API 获取热门话题 {#getting-trending-topics-with-the-sorsa-api}

趋势接口接受单个查询参数 woeid，返回一列趋势对象。没有历史模式，也没有分页：每次调用返回请求那一刻的当前列表。

请求：

GET https://api.sorsa.io/v3/trends?woeid=23424977
Header: ApiKey: YOUR_API_KEY

响应：

{
  "trends": [
    {
      "name": "#FedDecision",
      "query": "%23FedDecision",
      "url": "https://twitter.com/search?q=%23FedDecision"
    },
    {
      "name": "Powell",
      "query": "Powell",
      "url": "https://twitter.com/search?q=Powell"
    },
    {
      "name": "rate cut",
      "query": "%22rate+cut%22",
      "url": "https://twitter.com/search?q=%22rate+cut%22"
    }
  ]
}

每个趋势对象有三个字段：

• name：热门话题的人类可读标签。在你的 UI 里显示这个。
• query：URL 编码的搜索字符串。传给搜索接口，取回趋势背后的实际帖子。
• url：到 X 搜索结果页的一个直接链接，对看板或提醒里的可点击引用有用。

要构建一份历史记录，按你自己的节奏轮询、并存下每份快照。每个地点每 10 到 15 分钟运行一次、写进一个时间序列存储，几周内就变成一个可用的数据集。完整的请求和响应形状记录在趋势接口参考里，快速上手指南则走一遍如何拿一个密钥。

WOEID 参考：主要国家和城市 {#woeid-reference-top-countries-and-cities}

下表覆盖生产里最常出现的 WOEID。对每个支持的地点，用公开 WOEID gist。

全球

国家

主要城市

对更小的城市和区域市场，用完整 WOEID gist。

代码示例：Python、Node.js 和 curl {#code-examples-python-nodejs-and-curl}

下面三个示例都打同一个接口、且只需要 ApiKey 请求头里一个 API 密钥。

curl

curl -H "ApiKey: YOUR_API_KEY" \
  "https://api.sorsa.io/v3/trends?woeid=23424977"

Python

import requests

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
headers = {"ApiKey": API_KEY}

# 美国趋势（WOEID 23424977）
resp = requests.get(f"{BASE}/trends", headers=headers, params={"woeid": 23424977})
trends = resp.json()["trends"]

for t in trends[:10]:
    print(t["name"], "->", t["url"])

Node.js

const API_KEY = "YOUR_API_KEY";

async function getTrends(woeid) {
  const res = await fetch(`https://api.sorsa.io/v3/trends?woeid=${woeid}`, {
    headers: { ApiKey: API_KEY },
  });
  const { trends } = await res.json();
  return trends;
}

// 美国趋势
getTrends(23424977).then((trends) => {
  trends.slice(0, 10).forEach((t) => console.log(t.name, t.url));
});

并行轮询多个区域

当你一次追踪几个市场时，就并发发出请求，而不是塞在一个循环里。固定的每秒 20 次请求限制，让少数几个区域轻而易举。

import asyncio
import aiohttp

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
WOEIDS = {"US": 23424977, "UK": 23424975, "Japan": 23424856, "Brazil": 23424768}

async def fetch_trends(session, name, woeid):
    url = f"{BASE}/trends"
    async with session.get(url, headers={"ApiKey": API_KEY}, params={"woeid": woeid}) as r:
        data = await r.json()
        return name, [t["name"] for t in data["trends"][:10]]

async def main():
    async with aiohttp.ClientSession() as session:
        tasks = [fetch_trends(session, n, w) for n, w in WOEIDS.items()]
        for name, tops in await asyncio.gather(*tasks):
            print(name, tops)

asyncio.run(main())

把趋势与搜索结合以做更深分析 {#combining-trends-with-search-for-deeper-analysis}

单看一个趋势名，只告诉你一个短语很热。价值来自拉取趋势背后的帖子，而预建的 query 字段，把这一步变成一次额外调用，而不是一场查询构建练习。当你确实需要手动构造过滤时，搜索查询构建器为你组装语法。query 到达时是 URL 编码的，所以在传给期待纯文本的搜索接口之前，先解码。

import requests
from urllib.parse import unquote_plus

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
headers = {"ApiKey": API_KEY}

# 1. 获取当前美国趋势
trends = requests.get(
    f"{BASE}/trends", headers=headers, params={"woeid": 23424977}
).json()["trends"]

# 2. 对头几个趋势，拉驱动每一个的帖子
for trend in trends[:5]:
    body = {"query": unquote_plus(trend["query"]), "order": "popular"}
    posts = requests.post(f"{BASE}/search-tweets", headers=headers, json=body).json()["tweets"]
    print(trend["name"], "->", len(posts), "top posts")

从这里，你能按那些帖子上的互动给账号排名、给情感分类，或把任何匹配一份观察列表的东西路由进 Slack。搜索步骤在我们的 Twitter 搜索 API 指南里端到端覆盖，常开版本则在实时监测走查里运行。因为趋势拉取和每次搜索都是按请求计的单次调用，一条趋势到帖子的数据管道即便在高频下也保持便宜。

官方 X 趋势接口的常见问题 {#common-issues-with-the-official-x-trends-endpoint}

官方 X 趋势接口通常返回比预期更少的趋势，默认每个地点约 20 个，而不是较老的 v1.1 接口返回的 50 个。接口偶尔还会在平台侧问题期间返回一个空列表。其 tweet_count 字段即便通过 trend.fields 请求，也经常为 null，且访问仅限付费 API 层级。

这些不是边缘情况，它们在 X 自己的开发者论坛里反复出现：

• 只有约 20 个趋势。 在 v2 上调用 GET /2/trends/by/woeid/{woeid} 的开发者报告收到大约 20 项，但文档并不承诺 v1.1 过去返回的 50 个。如果你确实需要一个更长的列表，就得在这个默认值和接口的结果数参数范围内想办法。
• 空响应。 在平台事故期间，接口对每个 WOEID 一次返回空白趋势列表。这反映的是上游数据，而不是你的代码，所以任何生产轮询器都需要优雅地处理一个空数组。
• 缺失推文量。 tweet_count 字段本意是携带每个趋势的量，但多个开发者报告：它即便在 trend.fields 正确设置时也返回 null。把那个数字当作可靠，是一个错误。
• 付费层级和 OAuth 开销。 趋势不属于任何免费额度，且每次调用都需要一个绑定到已注册应用的 Bearer 令牌，那是起步最慢的部分。
• v1.1 的踪迹是一条死路。 较老的教程指向 v1.1 里的 GET trends/place，而 X 已把它弃用。从那些指南复制的代码跑不通。

这就是单密钥替代方案存在的实际原因。通过一个像 Sorsa 这样的替代性 Twitter/X API 拉趋势，绕开 OAuth 搭建和按资源计费：一次请求返回完整当前列表，并给每个趋势配一个即用的搜索查询。推文量缺口对两条路径都适用，而诚实的答案也一样：在一个时间窗口内，为某个趋势数一数搜索结果，以此派生量。这是一个比平台留空的字段更真实的度量。

趋势数据的用例 {#use-cases-for-trend-data}

趋势数据在接进一条真实数据管道之前，看起来像是装饰性的。下面这些，是驱动多数生产使用的模式。

实时内容营销。 社交团队每 10 到 15 分钟拉区域趋势、对照品牌声音规则打分，并挑出那些可以安全互动的。最初的奥利奥超级碗时刻就是这套做法的手动版本；自动化版本则跑在一条趋势信息流上。

新闻编辑室提醒。 新闻席位盯着一个主要市场，加上几个接壤的，并在一个陌生话题进入前十时触发一个 Slack 提醒，往往在故事到达通讯社之前就抓到。

交易信号研究。 量化团队在一个紧密的间隔上拉目标市场的趋势，并对照股票代码和板块关键词交叉引用。一个趋势话题有时先于对应的价格波动，这让它成为一个有用的输入层。

本地化活动规划。 代理商每天一到两次，拉取客户运营的每个市场的趋势，来决定哪条创意发到哪里。产出通常是一张表或 BI 看板，而不是一个实时系统。

品牌和危机监控。 一个品牌或产品在区域趋势里突然出现，往往是一个公关事件最早的信号。把趋势与提及追踪配对，就把这变成一个便宜、可靠的警报，也能自然接入社交聆听或竞品追踪工作流。

在以上每一种里，趋势调用都是便宜的那部分。真正的工作是你拿结果做什么，这就是为什么按请求定价在这里比乍看起来更要紧。

速率限制、缓存和最佳实践 {#rate-limits-caching-and-best-practices}

大规模跑这个的几条实际说明。

激进地缓存。 趋势最多每几分钟变一次，所以每个 WOEID 缓存结果 5 到 10 分钟，就覆盖几乎每个用例，并把请求量削减几个数量级。带一个 TTL 的 Redis 是最简单的实现。

尊重速率限制。 Sorsa 跨所有接口（包括 /trends）对每个 API 密钥强制固定的每秒 20 次请求。每 30 秒轮询 20 个区域没问题；每秒轮询 200 个区域不行，会返回 429 Too Many Requests。对更高吞吐，速率限制页覆盖自定义限制。

处理空列表。 一些更小的 WOEID 偶尔返回短的或空的数组。这很正常，反映的是底层 X 数据，所以要做防御性编码。

搜索用 query 字段，而不是 name。 name 是人类可读的，但可能含需要转义的字符。query 已经是 URL 编码的，也是 X 内部所用的；在把它传给搜索接口之前先解码。

错开排定的轮询。 追踪 50 个 WOEID 时，别在分钟边界一次发出全部 50 个。把它们分散在一个 30 秒窗口里，以避免突发负载。文档也覆盖大规模优化 API 使用的请求模式。

实战中：为一个新闻编辑室席位轮询趋势 {#in-practice-trend-polling-for-a-newsroom-desk}

最倚重趋势数据的团队是社交新闻编辑室和品牌监控席位。我们合作过的一个大约 12 人的媒体分析组，每几分钟跨八个市场轮询区域趋势，来抢先抓到突发故事。

在官方 API 的按量付费模型上，每五分钟跨八个市场、每个市场读约 30 个趋势，累加得很快。每个返回的趋势都是一个单独计费的资源，一个繁忙的月份会把用量推向平台的读取上限。把同样的轮询搬到一个按请求计费的套餐，就把这一切塌缩成一个可预测的月度数字，并完全移除按资源核算。一次地点拉取算作一次请求，不管回来多少趋势。这个节省不是什么巧妙的优化，而是直接来自按请求计费。在这个量上，它比按资源计费便宜得多，也就是上面对比表里那个每次拉取约 100 倍的差距。

常见问题 {#frequently-asked-questions}

X API v2 有一个趋势接口吗？

有。X API v2 趋势接口是 GET /2/trends/by/woeid/{woeid}，接受一个 WOEID 作为路径参数，返回一列趋势对象，并通过 trend.fields 参数支持一个可选的 tweet_count 字段。认证用一个 OAuth 2.0 Bearer 令牌，访问仅限付费 X API 层级。旧的 v1.1 trends/place 接口已被弃用。

为什么 X 趋势接口只返回 20 个趋势或一个空响应？

X API v2 趋势接口默认每个地点返回约 20 个趋势，比退役的 v1.1 接口返回的 50 个更少，而且文档不保证一个固定的数目。接口也可能在平台侧事故期间返回一个空数组，这会一次影响所有 WOEID，而不是指示你请求里的 bug。生产轮询器应优雅地处理短的和空的列表。

有一个免费的 Twitter 趋势 API 吗？

2026 年通过官方 X API 没有免费趋势访问，因为趋势在付费层级之后，而读取按资源计费。免费爬虫和非官方接口是有，但往往被限速、且不可靠。要低成本又可靠地访问，可以用一个像 Sorsa 这样的替代性 Twitter/X API：注册即送 100 次免费请求（无需绑卡），之后按请求计费。一次趋势拉取在 Pro 套餐上约 $0.002，小工作负载一个月也就几美元。

官方 X 趋势 API 和 Sorsa 有什么区别？

官方 X 趋势接口返回趋势名，带一个可选、常为空的推文计数，并要求一个 OAuth 2.0 Bearer 令牌，处在一个按趋势读取计费的付费层级上。Sorsa /trends 接口返回的每个趋势名都带一个预建搜索查询和一个直接 URL，用单个 API 密钥认证，并按请求计费。对把趋势与搜索结合的数据管道，那个即用的 query 字段省掉了手动构建搜索语法的步骤。

Twitter 趋势包含推文量或计数吗？

官方 X 趋势接口暴露一个 tweet_count 字段，但开发者报告：该字段即便通过 trend.fields 请求也返回 null，所以并不可靠。Sorsa 接口不给每个趋势附一个量数字。在任一路径上，衡量量最真实的方式，是用趋势的 query 去查询搜索接口，并在一个固定时间窗口内数结果。

能获取特定城市的趋势吗？

能，只要 X 支持那个城市的趋势。市镇级 WOEID 覆盖全球多数主要都会区，在总共大约 470 个支持的趋势地点里。较小的城市通常没有专门的列表，会回退到国家级数据。公开 WOEID gist 列出每个支持的地点，其中任何城市都能作为 woeid 参数直接传入。

如何找到一个国家或城市的 WOEID？

对常见市场，查本指南里的参考表。对其他任何东西，GitHub 上的公开 WOEID gist 列出每个 X 支持的趋势地点及其数字 ID。如果一个地方不在那个列表里，X 就不在 API 层级为它发布趋势数据，所以没有 WOEID 可查询。

能获取历史 Twitter 趋势吗？

没有哪个趋势 API 返回历史数据；官方 X 接口和 Sorsa 接口都只返回当前列表。要构建历史，就按计划轮询、并存下每份快照，通常每个地点每 10 到 15 分钟写进一个时间序列数据库。因为 Sorsa 按请求计费，为一份历史存档做频繁轮询也保持不贵。

开始上手 {#getting-started}

到你第一个趋势列表，最快的路是：

1. 在 Sorsa 控制台创建一个账号并复制一个 API 密钥，没有开发者账号审批要等。
2. 用你 ApiKey 请求头里的密钥和一个像 1（全球）或 23424977（美国）的 WOEID 向 https://api.sorsa.io/v3/trends 发一个 GET 请求。
3. 把每个趋势的预建 query 字段传给搜索接口，取回驱动趋势的实际帖子。

每个新账号注册即送 100 次免费请求（无需绑卡），付费套餐则从每月 $49 换 1 万次请求起，每个层级都是固定的每秒 20 次请求。这个 API 自 2022 年以来已累计处理请求超 50 亿次。你能在 Sorsa Playground 里无需写代码试任意接口、读完整的 API 参考，或在我们的 Twitter API 替代方案指南里对比选项。对标准套餐之外的量，团队通过联系销售处理自定义限制。

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

本指南取材于我们打造并运营 Sorsa（一个替代性 Twitter/X API）的亲手工作、以及在这次更新期间对着官方接口测试实时 /trends 接口。官方接口的路径、结果行为和计费对照 X 的官方趋势文档和 X 关于结果限制及推文计数字段的开发者论坛话题串核验；WOEID 覆盖对照公开 WOEID gist核查。两个提供方的定价反映截至 2026 年 6 月 9 日当前的数字。最后核验于 2026 年 6 月 9 日。