GAS异步触发器按创建顺序执行及表格数据防覆盖方案

你当前方案的两个问题属于设计层面的必然缺陷，和锁实现、行号计算逻辑无关：

• GAS时间触发器本身不保证执行顺序：官方调度机制存在随机延迟，哪怕所有触发器都设置为1ms后触发，实际执行顺序和创建顺序没有强绑定关系，高并发下乱序是必然结果。
• 竞态条件位置错误：你之前把加锁逻辑放在单个触发器的业务执行段，多个触发器实例几乎同时启动时，会在拿到锁之前就完成空行号读取，等抢到锁写入时，多个实例拿到的行号完全一致，自然会出现覆盖。
• 额外稳定性隐患：GAS单项目的触发器存在明确配额限制，每个请求单独创建触发器的模式，请求量稍高就会触发配额报错，不适合生产环境使用。

这个模式可以完全实现HTTP请求和业务逻辑解耦，保证严格按请求到达顺序执行，无写入冲突，且不会触碰GAS配额限制。

核心逻辑 #

• 请求到达doGet后，仅做入队操作，加锁保证入队顺序和请求顺序一致，入队完成立刻返回响应，全程耗时不超过100ms，客户端无需保持连接等待。
• 全局仅保留1个队列消费触发器，队列无任务时自动删除触发器，有新任务入队时自动创建消费触发器，永远不会出现多个触发器同时消费的情况。
• 消费逻辑全程加脚本锁，从队列头部依次取任务执行，执行完成后再出队，从根源避免乱序和写入覆盖。

实现代码 #

Web请求入队逻辑 #

function doGet(e) {
  const lock = LockService.getScriptLock();
  lock.waitLock(5000);
  try {
    const propStore = PropertiesService.getScriptProperties();
    // 读取现有队列
    const queueStr = propStore.getProperty('task_queue') || '[]';
    const queue = JSON.parse(queueStr);
    // 当前请求参数入队，带时间戳做顺序校验
    queue.push({
      params: e.parameter,
      enqueueTime: Date.now()
    });
    propStore.setProperty('task_queue', JSON.stringify(queue));

    // 无消费触发器时才新建，保证全局仅1个消费者
    const existingConsumer = ScriptApp.getProjectTriggers().filter(t => t.getHandlerFunction() === 'consumeQueue');
    if (existingConsumer.length === 0) {
      ScriptApp.newTrigger('consumeQueue')
        .timeBased()
        .after(100)
        .create();
    }
  } finally {
    lock.releaseLock();
  }
  // 立刻返回响应，断开客户端连接
  return ContentService.createTextOutput('ok');
}

队列消费逻辑 #

function consumeQueue() {
  const lock = LockService.getScriptLock();
  // 抢不到锁说明已有消费实例在运行，直接退出
  if (!lock.tryLock(30000)) return;
  const SHEET_ID = 'XXXXXXX';
  const SHEET_NAME = 'STACKTEST';
  const propStore = PropertiesService.getScriptProperties();
  const sheet = SpreadsheetApp.openById(SHEET_ID).getSheetByName(SHEET_NAME);
  
  try {
    // 循环消费直到队列清空
    while(true) {
      const queueStr = propStore.getProperty('task_queue') || '[]';
      const queue = JSON.parse(queueStr);
      // 队列空了就删除当前触发器，退出循环
      if (queue.length === 0) {
        ScriptApp.getProjectTriggers()
          .filter(t => t.getHandlerFunction() === 'consumeQueue')
          .forEach(t => ScriptApp.deleteTrigger(t));
        break;
      }
      // 取队列头部任务（最早到达的请求）
      const currentTask = queue.shift();
      const p = currentTask.params;
      
      // 替换为你的实际业务逻辑，此处为测试用睡眠
      Utilities.sleep(30000);
      
      // 复用你之前优化的空行计算逻辑，单消费者模式下无行号重复问题
      const avals = Sheets.Spreadsheets.Values.get(SHEET_ID, `${SHEET_NAME}!A1:A`).values || [];
      const insertRow = avals.length + 1;
      sheet.getRange(insertRow, 1, 1, 5).setValues([[p.backteam, p.backodds, p.layteam, p.layodds, p.advantage]]);
      
      // 任务执行完成后更新队列
      propStore.setProperty('task_queue', JSON.stringify(queue));
    }
  } catch(err) {
    console.error('队列消费出错', err);
    // 可按需实现失败任务重试、错误日志记录逻辑
  } finally {
    lock.releaseLock();
  }
}

方案优势 #

• 响应速度极快：Web端请求处理耗时毫秒级，完全满足客户端发完即走的需求
• 顺序一致性保证：严格遵循先进先出规则，任务执行顺序和请求到达顺序完全一致
• 无写入冲突：单消费者模式+全局锁保护，空行计算、数据写入、队列更新操作全程原子化，不会出现行号重复、数据覆盖问题
• 配额友好：无论请求量多大，全局最多存在1个消费触发器，不会触发GAS触发器数量配额限制
• 兼容现有优化：你之前实现的Sheets API批量读空行逻辑可以直接复用，不需要调整已做的性能优化部分

适配调整提示 #

• 如果单批次累积任务总执行时长可能超过GAS单次执行6分钟的上限，可以在消费循环中增加执行时长统计，累计运行达到5分30秒时主动终止当前消费，创建新的触发器接续消费剩余任务即可，不会丢任务。
• 若日均请求量过万，可以将队列存储从脚本属性迁移到独立的隐藏工作表中，脚本属性单值最大支持100KB，足够承载数百个排队任务，大流量场景下表存储队列容量无压力。
• 锁请统一使用ScriptLock（脚本锁），不要使用文档锁，跨触发器实例场景下脚本锁的可靠性更高。

内容的提问来源于stack exchange，提问作者Digital Farmer