作者:Sorsa 编辑部

发布于 2026 年 6 月 13 日。更新于 2026 年 7 月 3 日。价格反映 2026 年 4 月 20 日更新后的官方 X API 按量付费费率,以及 Sorsa 当前的按请求套餐,于 2026 年 7 月核实。

更新于 2026 年 7 月:把 X API 和 Sorsa 的成本数字刷新为当前的按请求模型,把 Sorsa 价格改用每 1,000 条推文重述,并新增了 100 次免费请求的起步优惠。

核心要点: 把 Twitter (X) 数据导出到 Google Sheets 有四种方式:无代码连接器(IFTTT、Make)、Sheets 的 API 连接器加载项、低代码工作流(n8n),或挂在定时触发器上的 Google Apps Script。除无代码外,每条路线都需要一个 API 密钥,分页、调度和去重则由你自己处理。

难点很少在电子表格本身,而在于给表格供数据的数据源。Sorsa API 这个替代 Twitter/X API,用一个请求头就把公开推文、账号资料和粉丝列表以纯 JSON 返回,所以一次 Sheets 导出只需几行代码。计费按请求:无论返回多少条推文或资料,一次调用都只算一次请求,且作者资料免费包含在每条推文里。正是这种模型,让 Sorsa 在批量基准上从每 1,000 条推文 $0.02 起读取推文、在 Pro 套餐上从每 1,000 份 $0.01 起读取资料,而官方 X API 每 1,000 次帖子读取收 $5.00(2026 年 4 月费率,于 2026 年 7 月核实)。没有会榨干定时任务的按推文计价表,限制是每个套餐固定每秒 20 次请求,一次性的 100 次免费请求让你在付费之前就把整套导出搭好并测试,无需绑卡。

目录

如何把 Twitter 数据导出到 Google Sheets? {#how-do-you-export-twitter-data-to-google-sheets}

把 Twitter 数据导出到 Google Sheets,意味着从 API 拉取推文、资料或粉丝列表,并把每条记录写成一行。四条路线覆盖所有情况:面向你自己账号做简单动作的无代码连接器、在表格内部调用 API 的 Sheets 加载项、低代码工作流工具,或自定义脚本。选哪一个取决于数据量、对字段结构的掌控,以及你的技术水平。

每条路线都建立在同一个想法上:某个东西调用一个接口、收到 JSON,然后每条记录追加一行。区别在于掌控力。无代码小程序把请求藏起来,给你固定的列;脚本则暴露完整响应,让你自己决定字段结构、调度周期,以及如何处理重复项。

选择之前有一个区别要紧。拉取与你自己账号绑定的数据(你的帖子、你的粉丝)几乎在哪里都很简单。规模化地拉取任意关键词、提及或其他账号,则需要一个能直接返回搜索和时间线数据的 API。因为在 2023 年 API 变更之后,内置于无代码工具里的官方平台连接器受到了严格限制。

你该用哪种导出方法? {#which-export-method-should-you-use}

用 Apps Script 做带自定义字段结构的生产级导出,用加载项或 n8n 做无需多少代码的定时导入,无代码连接器则只用于你自己账号上的简单动作。设置耗时从无代码的十分钟以内,到一套完整 Apps Script 的两三个小时不等,只有脚本路线才能给你可靠的去重和精确的列控制。

方法设置耗时技术要求定时调度去重最适合
无代码(IFTTT、Make)10 分钟以内有限你自己的账号、简单动作
Sheets API 连接器加载项15 至 30 分钟支持手动无需写代码即可访问 API
n8n 工作流30 至 60 分钟低到中支持配合数据存储可视化数据管道、自托管
Google Apps Script1 至 2 小时支持完全掌控自定义字段结构、生产级导出

这里的权衡是掌控力对上工作负载。如果一套固定的列和大致的时间就够用,连接器或加载项能帮你省下一个下午。但如果下游报表依赖精确的字段结构,或者重复项会污染你的数字,那么脚本路线值得那点额外的设置成本。

用 Google Apps Script 把推文拉进 Sheets {#pull-tweets-into-sheets-with-google-apps-script}

Google Apps Script 是最灵活的路线:一个在 Google 基础设施内部运行的 JavaScript 函数,调用 API、写入行,并挂在一个基于时间的触发器上以便自动运行。它是唯一能对字段结构、去重、错误处理和日志完全掌控的选项,而且不需要任何第三方连接器。

下面的示例为一个搜索查询拉取推文,并把新推文追加到一个标签页里。脚本调用 Sorsa 的推文搜索接口,该接口接收一个查询以及 popularlatest 的排序,每页返回最多 20 条推文并附带作者资料。按以下步骤操作:

  1. 在你的 Google Sheet 里新建一个名为 Tweets 的标签页。
  2. 打开“扩展程序”菜单,选择 "Apps Script"。
  3. 在“项目设置”里,添加一个名为 SORSA_API_KEY 的脚本属性,填入你的密钥。
  4. 粘贴下面的函数,并设置你的搜索查询。
  5. 运行一次该函数,并批准授权提示。
  6. 打开“触发器”,添加一个时间驱动的触发器,选一个运行间隔。
javascript
function exportTweetsToSheet() {
  var apiKey = PropertiesService.getScriptProperties().getProperty('SORSA_API_KEY');
  var query = 'your search query here';

  var response = UrlFetchApp.fetch('https://api.sorsa.io/v3/search-tweets', {
    method: 'post',
    contentType: 'application/json',
    headers: { 'ApiKey': apiKey },
    payload: JSON.stringify({ query: query, order: 'latest' }),
    muteHttpExceptions: true
  });

  var status = response.getResponseCode();
  if (status === 401) { Logger.log('Unauthorized: check the ApiKey value'); return; }
  if (status === 429) { Logger.log('Rate limited: wait one second, then retry'); return; }
  if (status !== 200) { Logger.log('Unexpected status: ' + status); return; }

  var tweets = (JSON.parse(response.getContentText()).tweets) || [];
  var sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Tweets');

  // 把 ID 列保持为文本,这样 19 位的 ID 才不会丢失精度
  sheet.getRange('A:A').setNumberFormat('@');

  if (sheet.getLastRow() === 0) {
    sheet.appendRow(['tweet_id', 'created_at', 'username', 'full_text',
                     'likes_count', 'retweet_count', 'reply_count']);
  }

  var lastRow = sheet.getLastRow();
  var seen = lastRow > 1
    ? sheet.getRange(2, 1, lastRow - 1, 1).getValues().flat().map(String)
    : [];

  var added = 0;
  tweets.forEach(function (t) {
    var id = String(t.id || '');
    if (!id || seen.indexOf(id) !== -1) return;
    var user = t.user || {};
    sheet.appendRow([id, t.created_at || '', user.username || '', t.full_text || '',
                     t.likes_count || 0, t.retweet_count || 0, t.reply_count || 0]);
    added++;
  });

  Logger.log('Done. Added ' + added + ' new tweets.');
}

两点实用提示。把密钥放进脚本属性里,绝不要硬编码在函数体里,这样密钥就不会留在共享的脚本历史中。以及,如果语法不熟,先把查询可视化地搭出来:可视化查询构建器能把 from:since:until: 等高级搜索操作符变成一段测试过、可直接粘贴的字符串。

要采集不止一页,就从响应里读取 next_cursor 字段,并把游标放进请求体再次调用,直到游标返回 null。这套机制在各分页接口上都一样;游标分页参考展示了这个循环。要导出粉丝列表而非推文,就用一个用户名调用粉丝接口;每页返回最多 200 份资料,这让一次大型粉丝列表导出也只需寥寥几次请求。

无代码与低代码路线 {#no-code-and-low-code-routes}

无代码和低代码工具用掌控力换取速度。IFTTT 和 Make 几分钟就能把 X 连到 Google Sheets,适合与你自己账号绑定的简单动作;n8n 高一个层级,带有真正的逻辑;Sheets 加载项则直接从表格内部调用 API。这些工具在去重和自定义字段结构上,都没有脚本处理得那么干净。

纯无代码路线上一个诚实的限制:在 2023 年平台变更之后,这些工具里内置的 X 连接器面向的是你自己的账号和发帖。它们不是用来把任意搜索结果读进一个数据存储的。用来记录你自己的帖子或对你自己的活动做出反应,它们很好用。但要规模化地监测关键词、提及或竞品,你会想要一个能返回搜索和时间线结果的数据源,通过加载项或脚本来喂。

n8n 是最强的折中方案。你可视化地构建一个工作流,但保留分支、转换、分页循环和一个调度触发器。典型形态是:一个调度触发器、一个调用搜索接口的 HTTP Request 节点、一个把响应数组拆成条目的节点,以及一个把每一行追加进去的 Google Sheets 节点。由于 n8n 能保存状态,你可以像脚本那样加一个去重步骤。

像 API 连接器这样的 Sheets 加载项,让你在表格内部配置一个 URL、请求头和参数,然后按计划刷新。当你想要无需写代码的定时导入时,它们很合适。请把 API 密钥放在请求头里而非 URL 中,这样密钥就不会出现在日志或浏览器历史里。

你的导出该有哪些列? {#what-columns-should-your-export-have}

一份干净的导出,让你每条推文一行,配以稳定、有名字的列。至少要采集推文 ID、时间戳、作者用户名、文本,以及三项核心互动计数。ID 是去重的唯一键,应存为文本;其余一切都从响应里直接映射。

Sorsa 字段说明
tweet_idid存为文本;去重的唯一键
created_atcreated_atISO 8601 时间戳
usernameuser.username嵌套在作者对象之下
full_textfull_text完整的推文文本
likes_countlikes_count整数,用 0 而非留空
retweet_countretweet_count整数
reply_countreply_count整数

把表头当作一份契约:一旦某个报表或公式依赖了这些列,重命名一列就会悄悄弄坏东西,所以字段结构定义一次就保持下去。由于作者资料会返回在每条推文里,用户名和粉丝数来自同一个响应、无需额外请求。这也是按请求计费的账单在这里能保持低位的部分原因。

上线前的常见坑 {#common-gotchas-before-you-ship}

三个问题绊住了大多数第一次导出:推文 ID 丢失精度、定时运行静默失败,以及分页悄悄停在第一页。每个都有简单的修法,一开始就做对,能省下日后报表已经接上表格后的一次重建。

推文 ID 太大,Sheets 无法当作数字存储。 推文 ID 是 18 到 19 位的值,而 Google Sheets 把数字存为 64 位浮点数,只保留约 15 位有效数字。末尾几位会舍入为零,ID 就不再与真实推文匹配。请把 ID 列格式化为纯文本,或在值到达表格之前就把 ID 写成字符串。

分页不是自动的。 搜索和时间线接口每页返回约 20 条记录;粉丝接口返回最多 200 条。要越过第一页,就在 next_cursor 值上循环,直到游标返回 null。批量接口在数据适合时能帮上忙:当你已握有最多 100 个推文 ID 或 100 个用户名时,一次批量调用就全部返回,这是削减请求量的主要杠杆。

定时运行可能失败而不告诉你。 一个出错的基于时间的触发器,除非你自己搭了告警,否则不会通知你。在 catch 块里加一个 MailApp.sendEmail 调用,或按计划检查 Apps Script 的执行日志。遇到速率限制时,一个 429 只是意味着等一秒再重试;每个套餐都是固定每秒 20 次请求,一个合理的间隔很少会撞上。

做这件事需要官方 Twitter/X API 吗? {#do-you-need-the-official-twitterx-api-for-this}

不需要,把数据读进表格用不着它。官方 X API 只在发帖或发私信等写操作时才需要。对于读取公开推文、资料和粉丝列表,一个只读替代方案按请求而非按资源计费,这在同一次导出上就是几美分和几美元之间的差别。

成本差距来自双方各自的计价方式。官方 X API 按抓取的资源计费,每 1,000 次帖子读取 $5.00,外加每 1,000 份用户资料 $10.00,硬性上限为每月 200 万次帖子读取(2026 年 4 月费率,于 2026 年 7 月核实,详见我们的 X API 价格详解)。按请求计费的模型则把一次调用算作一次请求,并把作者资料免费折算进去,这让同样的读取在 Sorsa 的搜索基准上约合每 1,000 条推文 $0.10,或在其批量基准上从每 1,000 条 $0.02 起。

任务(读取,写入表格)官方 X API(按量付费)Sorsa(Pro 套餐)
1,000 条推文(含作者资料)~$5 至 $15(帖子加用户读取)低至 $0.02(批量基准)
10,000 份粉丝资料~$100(10,000 次用户读取)~$0.10(每次请求 200 份)
每月读取上限2,000,000 次帖子读取,之后被封锁按请求套餐,无按推文计价表

对于发帖或私信,官方 API 是唯一选项,那是它的地盘。对于以固定、可预测的价格把公开数据读进表格,只读 API 便宜得多、接线也更快,这正是它适合定时导出,以及那些整月运行的社交聆听方案的原因。同一个数据源也在同样的按请求账单上驱动着一个品牌提及追踪器

一套真实的导出方案 {#a-real-export-setup}

一个约十人的分析团队,在一次预算意外之后转向了这里。他们原本通过官方 API 把品牌提及和竞品帖子记录进 Sheets,每次定时拉取都按帖子和按作者读取计费。一旦他们每天追踪好几个关键词,费用就飙升得很快。把同样的读取迁到按请求计费的 API 后,那笔数据成本削减了最高 50 倍。这正是一个读密集型负载离开按资源计费后的预期结果,因为作者资料免费随行,一次批量调用只算一次。仅帖子读取一项,就从官方费率的每 1,000 条 $5.00 降到 Sorsa 搜索基准的约每 1,000 条 $0.10;按推文 ID 的批量采集落在约每 1,000 条 $0.02,两种方式都省下超过 98%。

构建本身保持得很小:每个关键词一个 Apps Script、一个每小时的触发器、以推文 ID 作为去重键,以及一个单独的“已见 ID”标签页。这好让查找在表格变大时仍然快。他们得到的一课是关于匹配度,而非工具。Sheets 是一个不错的报表界面,却是一个糟糕的仓库;超过几十万行就变慢,那正是该把原始数据挪进数据库、把 Sheets 留作其上视图的时机。

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

不写代码能把 Twitter 数据导出到 Google Sheets 吗?

能,但有限度。IFTTT、Make 等无代码平台能把 X 连到 Google Sheets,最适合与你自己账号绑定的简单动作。要规模化地读取任意关键词、提及或其他账号,更可靠的做法是一个 Sheets 加载项,或一段调用像 Sorsa 这样的只读 API 的短小 Apps Script。它掌控分页、调度,以及写入哪些列。

为什么推文 ID 在 Google Sheets 里看起来不对?

推文 ID 是 18 到 19 位的数字,而 Google Sheets 把数字存为 64 位浮点数,只保留约 15 位有效数字。末尾几位会舍入为零,于是 ID 就不再与真实推文匹配。改为把 ID 存为文本:把 ID 列格式化为纯文本,或在值到达表格之前就把 ID 写成字符串。

定时导出时如何避免重复行?

用推文 ID 作为唯一键。每次定时运行之前,先读取表格里已有的 ID,然后跳过任何 ID 已存在的推文。对于大表格,单独保留一个只放“迄今已见 ID”的标签页,好让查找保持快速。由于每个推文 ID 都唯一,即使运行相互重叠,这也能防止重复。

Twitter 到 Sheets 的导出该多久运行一次?

把间隔匹配到数据驱动决策的频率。每小时适合对时间敏感的提及告警;每天足够趋势报表或关键词汇总;每周适合变动缓慢的审计。运行得比需要的更勤,会增加噪音,在按量计费的 API 上还会花钱却收效甚微。一个定时触发器让你设任意间隔,日后也可更改。

把数据导出到 Sheets 需要官方 Twitter API 吗?

不需要。官方 X API 只在发帖或发私信等写操作时才需要。对于把公开推文、资料和粉丝列表读进表格,像 Sorsa API 这样的只读替代方案通过单个 ApiKey 请求头工作、按请求计费。所以一次定时导出不会按推文计价。在 Pro 套餐上,批量基准从每 1,000 条推文 $0.02 起,而一次性的 100 次免费请求让你先把整套导出测试一遍。

Google Sheets 能装多少条推文?

单个 Google Sheets 文件在所有标签页合计最多容纳 1,000 万个单元格,具体能装多少行取决于你用了多少列。一个七列的推文导出,会在约 140 万行时触及该上限。截至 2026 年 4 月,Google 开启了一项将上限翻倍至 2,000 万单元格的 beta。超过几十万行,性能就会下降,此时数据库是更好的归宿。

如何开始 {#getting-started}

看清数据形态最快的方式,是在写任何代码之前先试一个查询。打开 API playground,运行一次搜索,读一读你将映射到各列的 JSON。当字段结构看起来没问题时,把上面的 Apps Script 放进你的表格,再加一个触发器。一次性的 100 次免费请求覆盖约 1 万条推文或 2 万份资料,足以在选套餐之前端到端地构建并验证导出,而且永不过期。

当你准备好扩容时,按请求套餐在批量基准上从每 1,000 条推文 $0.02 起读取推文、从每 1,000 份 $0.01 起读取资料,配以固定每秒 20 次请求,且无需排队审批。快速上手指南介绍了请求头认证和你的第一次调用。

审校:Keksich(Sorsa 创始人,X API 研究者)

本指南取材于我们团队运营 Sorsa API 的一线工作、实时 API 及其文档,外加 Google 关于定时触发器和请求头请求的官方 Apps Script 行为。Google Sheets 容量数字对照 2026 年 4 月的 Google Workspace 更新做了核对,X API 的按资源价格则在当前公开的价格详解与我们自己的价格拆解之间做了交叉核对。对比了四条导出路线。更多关于我们是谁的信息见关于页面。于 2026 年 7 月 3 日核实。