1. 过快发送大量邮件的后果 #

当你用Google Apps Script短时间内猛发大量邮件时，会碰到几个实打实的问题：

• 触发发送配额限制：Google给Apps Script的邮件发送有明确配额，免费个人账户每天最多100封，G Suite/Workspace用户配额更高但也有限制。短时间内超额发送会直接被临时封禁邮件发送功能，后续的邮件都会失败，还可能收到Google的官方警告。
• 账号被标记为风险账号：Google的反垃圾系统对异常发送行为很敏感，高频发送会被判定为疑似垃圾邮件发送者，轻则限制邮件功能，严重的话会牵连整个Google账号，比如Drive、Docs这些服务也会受影响。
• 邮件被扔进垃圾邮箱：就算没触发配额，短时间大量发送的邮件也容易被收件方邮箱服务商判定为垃圾，你的通知直接石沉大海，完全达不到推送的目的。

2. 批量删除条目时的异常邮件问题 #

从你的场景来看，这大概率是触发器和批量操作的逻辑冲突导致的，我给你分析下原因和解决办法：

问题根源 #

• 触发器高频触发/逻辑误判：如果你的脚本用的是简单的onEdit或者基础版onChange触发器，批量删除大量行时，触发器可能会被多次触发，或者因为行快速删除导致脚本的判断逻辑出错——比如把批量删除当成了多次单独的归还操作，甚至错误触发逾期提醒的逻辑。
• 行索引偏移bug：批量删除行的时候，脚本在处理某一行的同时，后面的行索引已经因为前面的删除发生了变化，导致脚本读取到错误的行数据，进而发送了不该有的邮件。
• 未处理批量操作边界：你的脚本应该只考虑了单条条目修改/删除的情况，完全没适配批量操作的场景，所以一次删N行就会触发N次邮件逻辑。

解决办法 #

• 改用可安装onChange触发器并判断操作类型：放弃简单的onEdit，换成可安装的onChange触发器，在脚本里先判断触发的操作是不是REMOVE_ROW，再通过删除前后的行数差判断是不是批量操作。如果是批量删除，就发一封汇总邮件，而不是逐行发。
  给你个代码片段参考：

  function handleChromebookChanges(e) {
    if (e.changeType === 'REMOVE_ROW') {
      const activeSheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
      // 计算删除的行数：删除前的行数 - 当前行数
      const deletedRows = e.oldValue - activeSheet.getLastRow();
      
      if (deletedRows > 1) {
        // 批量删除，发送汇总通知
        MailApp.sendEmail(
          'your-email@school.com', 
          '批量Chromebook归还通知', 
          `工作人员批量删除了${deletedRows}条设备借出记录，请留意核对。`
        );
      } else {
        // 单条删除，执行原有详情通知逻辑
        // 这里放你原来的单条归还邮件代码
      }
    }
  }
  

• 添加防抖合并机制：对于高频触发的情况，可以设置一个短暂的延迟（比如3秒），在延迟时间内如果有多次触发，就合并成一次处理。可以用Script Properties来记录最后触发的时间，判断是否需要合并操作。
• 优化行数据读取逻辑：处理删除操作时，不要依赖实时的行索引，尽量通过事件对象e的信息（如果可用），或者在删除前缓存要处理的行数据，避免行偏移导致的错误判断。
• 限制邮件发送频率：在脚本里加个计数器，比如1分钟内最多发送2封邮件，超过的话就把多条通知合并成一封汇总邮件，避免短时间内收到一堆冗余邮件。

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