1 篇博文 含有标签「chrome.alarms」

MV3 扩展用 chrome.alarms 设了 10 秒周期定时 flush 日志，上线后发现生产环境实际每分钟才触发一次，定时完全不准。

在为客户开发 电商数据采集工具 时遇到此问题——扩展的 background service worker 需要定期把累积的客户端日志批量上报服务端，本来想用 10 秒一次保证实时性，结果生产环境里最坏要等整整一分钟。

TL;DR​

MV3 的 service worker 会休眠，定时任务只能用 chrome.alarms（setInterval 不可靠）；而 Chrome 对 chrome.alarms 在生产环境强制了约 1 分钟的最小周期，periodInMinutes < 1 会被悄悄提升到 1。解法是把 1 分钟当兜底，再靠「buffer 攒满即时触发」补上高频时段的延迟。

问题现象​

日志上报 relay 这样写，期望每 10 秒 flush 一次：

// background.js (MV3 service worker)
chrome.alarms.create('log-flush', { periodInMinutes: 0.16 }); // 想要 ~10s

chrome.alarms.onAlarm.addListener((alarm) => {
  if (alarm.name === 'log-flush') {
    flushLogs();
  }
});

本地开发（unpacked）跑起来好像没问题，打包发布到商店后实测：监听器每分钟才触发一次，periodInMinutes: 0.16 被 Chrome 无视了。没有任何报错，就是定时被拉长。

根因​

两层原因叠在一起。

第一层：MV3 下 setInterval 不可用。 Manifest V3 的 background 是 service worker，Chrome 会在它空闲约 30 秒后挂起以省电。挂起后 setInterval 直接停止，醒来也不会补跑错过的那几轮。所以任何「即使页面/扩展空闲也要执行」的定时任务，必须用 chrome.alarms——它是 Chrome 原生的、能唤醒 service worker 的调度机制。

第二层：chrome.alarms 有最小周期下限。 出于性能和续航考虑，Chrome 长期对 alarms 强制约 1 分钟的最小周期：periodInMinutes < 1 会被钳制到 1。开发环境（unpacked / Dev channel）放得更宽，能跑出更短的周期，于是本地测试通过；但打包成正式版发布后，Chrome 会把它对齐回 1 分钟。这就是「本地正常、线上拉长」的根源。

两个约束合起来：你不得不用 chrome.alarms，又不能指望它短于 1 分钟。

解决方案​

既然 1 分钟是硬下限，就把它当「最坏情况兜底」，再用事件驱动的即时触发补足实时性——双保险：

// 1. 兜底定时：1 分钟一次，保证 service worker 挂起也能被唤醒 flush
const FLUSH_THRESHOLD = 50;
chrome.alarms.create('log-flush', { periodInMinutes: 1 }); // 不再挣扎于 < 1

chrome.alarms.onAlarm.addListener((alarm) => {
  if (alarm.name === 'log-flush') {
    flushLogs().catch(() => {});
  }
});

// 2. 即时触发：日志进 buffer 时检查，攒满阈值就立刻 flush，不等闹钟
messageBus.on('log', (entry) => {
  pushBuffer([entry]);
  if (memBuffer.length >= FLUSH_THRESHOLD) {
    flushLogs().catch(() => {}); // 高频时段几秒内就能凑满触发
  }
});

这个组合把两个约束都吃下了：

• 1 分钟兜底解决「service worker 挂起后定时还在不在」——chrome.alarms 会按时唤醒 worker 执行，最坏延迟被锁在 1 分钟内，日志不会因为扩展空闲而无限积压；
• buffer 满即时触发解决「高频时段要不要等满一分钟」——只要短时间内累积达到阈值，就绕过闹钟立刻 flush，低频靠闹钟、高频靠事件，两端都不卡。

迁移代价极小：把原本指望「10 秒一次」的地方，改成「buffer 满 50 条 或 1 分钟，谁先到谁触发」。日志这类本就批量友好的场景几乎零成本；对延迟敏感的单条任务，则该重新设计成事件驱动而非轮询。

常见问题​

为什么 chrome.alarms 设置的周期不生效，被拉长到 1 分钟？​

Chrome 出于性能和续航考虑，对 alarms 强制约 1 分钟的最小周期，periodInMinutes 小于 1 会被钳制到 1。开发环境（unpacked）通常放得更宽能跑更短，但发布到商店的正式版会被对齐回 1 分钟，所以本地测正常、线上被拉长。

MV3 service worker 里能用 setInterval 做定时任务吗？​

不可靠。MV3 的 service worker 空闲约 30 秒就会被 Chrome 挂起，setInterval 随之停止，醒来也不会补跑错过的轮次。需要持久定时必须用 chrome.alarms（它能唤醒 worker），或把状态持久化到 chrome.storage、worker 唤醒时按时间差补做。