给店里报价单接了 Sheets API，我把「实时」改成了 15 分钟

店里有台老收银机改的报价机，装的是 Chrome 118，跑一个内部页面，数据源是客户自己维护的一张 Google 表。表不大，800 多行 SKU，20 来个列。原来的做法是页面每次打开都去拉一遍 Sheets API，老板改完价，前台刷新就能看到。听着挺美，实际用起来天天有人喊「价格不对」——多半是刚好卡在改完还没刷新的那几十秒里。

我先别急，把拉取逻辑收拢到一个 Apps Script 里，用时间驱动每 15 分钟跑一次，把整张表读出来写进缓存表，前端只认缓存。核心就这几行：

function syncSheet() {
  const src = SpreadsheetApp.openById(SRC_ID).getSheetByName('SKU');
  const dst = SpreadsheetApp.openById(CACHE_ID).getSheetByName('cache');
  const rows = src.getRange(2, 1, src.getLastRow() - 1, 20).getValues();
  dst.getRange(2, 1, rows.length, 20).setValues(rows);
  dst.getRange('V1').setValue(new Date());
}

前端改成读缓存表，页面上挂个「数据截至 xx:xx」的小字。

为什么这么干：Sheets API 按次计费不说，前台每次刷新都打一次接口，遇到几个手快的连点，配额掉得比你想的快。改成定时同步，接口调用从「看人」变成「看表」，一天 96 次，稳。代价是数据最多晚 15 分钟，这个我跟老板讲清楚了，他改价本来也不是秒级的事。

哪里会失效：一是 Apps Script 单次执行有 6 分钟上限，表再大点、列再多点就得拆批；二是 getLastRow 遇到中间空行会截断，我踩过一次，末尾 30 多个 SKU 凭空没了，后来改成按固定列算行数；三是缓存表被人手动改过一格，前端就对不上，现在同步前先清空再写。

你们那边前端读表，是直连还是走一层缓存？中间这层延迟一般卡在多少？