如何配置Google Drive Changes API仅推送文件新建删除的webhook通知

这个需求完全可行。当前产生冗余通知的核心原因是，Google Drive 的 webhook 机制本身不会在推送端对变更类型做筛选，所有匹配监控范围的文件状态变更（包括打开查看、内容修改、权限调整等）都会触发webhook回调；你之前的逻辑因为没有对拉取到的变更条目做类型过滤，导致查看类的变更也被纳入了推送流程。只要在服务端按变更类型做筛选，只保留符合要求的新建、删除类变更，即可彻底屏蔽冗余通知。

Google Drive v3 版本的变更条目自带明确的类型标识changeType字段，不需要依赖模糊的文件状态判断，直接根据这个字段的值做筛选即可：

• 触发目标通知的类型：file.created（新文件创建完成）、file.removed（文件被永久删除）
• 需要过滤掉的冗余变更类型：file.viewed（打开查看文件）、file.modified（文件内容修改、重命名、移动位置、移入回收站）、permission.changed（文件权限调整）、drive.settings.changed（网盘全局设置调整）

注意：Google Drive webhook 本身不支持在创建监控通道时配置“仅推送某类变更”，所有的类型筛选逻辑必须在你的服务端实现，无法通过Google侧的参数配置直接跳过冗余通知的推送。

1. 基础监控配置校验 #

在初始化Google Drive变更监控时，调用drive.changes.getStartPageToken接口时必须显式设置includeRemoved: true，后续拉取变更列表的请求也要保持这个配置，否则文件被删除时不会返回对应的变更条目（个人云盘、共享盘场景下该参数默认关闭，必须显式开启才能正常接收删除类通知）。

2. Webhook路由基础处理逻辑 #

Express 侧的webhook路由需要满足Google的响应要求：收到请求后5秒内返回200状态码，否则Google会触发重试逻辑。核心处理流程如下：

• 首先校验请求的JWT签名，拦截伪造的恶意请求
• 快速返回200响应，避免触发重试
• 根据本地存储的最新pageToken，调用drive.changes.list接口拉取对应时间段的全量变更条目（webhook回调本身只携带通道标识，不携带具体变更内容）
• 对拉取到的变更条目按changeType字段做过滤，仅保留新建、删除类的有效变更
• 仅将过滤后的有效变更传入后续的用户通知推送流程
• 更新本地存储的最新pageToken，供下一次变更拉取使用

3. 参考代码片段 #

// 引入Google Drive SDK、Express、JWT校验工具等依赖
app.post('/webhook/google-drive', express.json(), async (req, res) => {
  // 第一步：校验Google推送请求的合法性，防止伪造请求
  const isRequestValid = await verifyGoogleRequestSignature(req);
  if (!isRequestValid) return res.sendStatus(403);
  // 第二步：即时返回200，满足Google的响应时效要求
  res.sendStatus(200);

  // 第三步：拉取当前通道对应的最新变更列表
  const channelId = req.headers['x-goog-channel-id'];
  const storedPageToken = await getPageTokenByChannelId(channelId);
  const changeListRes = await drive.changes.list({
    pageToken: storedPageToken,
    fields: 'changes(changeType, file(id, name, trashed), removed), nextPageToken'
  });

  // 第四步：过滤目标变更类型
  const targetChanges = changeListRes.data.changes.filter(change => {
    // 保留新建、永久删除的变更
    if (['file.created', 'file.removed'].includes(change.changeType)) return true;
    // 可选：如果需要把文件移入回收站也算删除，可追加下面的判断
    // if (change.changeType === 'file.modified' && change.file?.trashed) return true;
    // 其余所有类型的变更直接丢弃
    return false;
  });

  // 第五步：仅对过滤后的有效变更触发通知推送
  if (targetChanges.length) {
    await sendUserNotification(channelId, targetChanges);
  }

  // 第六步：更新本地存储的最新pageToken
  await updatePageToken(channelId, changeListRes.data.nextPageToken);
});

• 不要把文件移动、重命名的变更误判为新建：这类操作的changeType为file.modified，不会被file.created的规则匹配，无需额外做逻辑判断
• 避免收到自身应用操作触发的变更：可以在拉取变更时，通过文件条目的appId字段过滤，如果是你的应用自身操作产生的变更，可直接跳过推送
• 注意webhook的pageToken必须持久化存储，不要每次拉取都从初始pageToken开始，否则会产生大量重复的历史变更

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