日历双向同步实战：把 Google / Outlook 日历接进你的 vibe 项目

先划三条界，免得和站内已有的指南撞车：本文不讲预约界面的设计与时区显示——自己做预约功能（时区三铁律、RRULE、冲突检测 SQL、预约状态机）请移步《日历预约实战指南》；也不讲站内通知中心（应用内的铃铛、未读数、推送通道编排），那是《通知系统指南》的地盘。本文只解决一个问题：当用户在他的 Google / Outlook 日历里新建、改动或删除了一个日程，你的 App 如何在秒级感知、增量同步，并且把用户在你 App 里做的修改写回去而不打架？

这是典型的"看起来简单、做起来全是坑"的功能。vibe 项目里最常见的翻车现场有三种：第一种，每 5 分钟全量拉一次用户日历，用户日程一多就撞上 API 配额，还被 Google 限流；第二种，webhook 收到了就直接信任，连签名都不验，等于给全世界开了个公开写入口；第三种，Google 侧删了一个会，你的库里还留着，用户在两个日历里看到的永远对不上——信任就是这么丢的。

本文给出一套完整方案：三档集成深度决策表 + OAuth 最小权限 + Google syncToken 增量同步 + watch 推送续约 + Outlook delta query + change notification 订阅 + 外部 ID 映射与删除墓碑 + 冲突裁决 + 时区同步坑 + 配额退避 + 合规清单。每一节都有可直接落地的代码，照着做，一个周末就能把"能用的日历同步"做成"可信的日历同步"。

一、先想清楚：你要的是哪一档集成？

90% 的返工都源于一开始选错了档。日历集成按"双向程度"分三档，成本差一个数量级：

档位	能力	典型场景	工程成本
A. 只读展示	拉取用户日程展示，不写回	日程聚合页、"看看你下周忙不忙"	低：一次 OAuth + 定时拉取
B. 单向写入	只往用户日历写事件（如预约确认）	预约系统、会议邀请发送	中：写 API + 幂等键
C. 双向同步	两边互相读写、冲突裁决	日程管理 App、CRM 时间线	高：本文全部内容

决策建议：默认从 A 起步，能用 B 就别上 C。双向同步的复杂度不在"调通 API"，而在冲突解决、删除传播、token 过期、推送续约这些长尾状态。一个实用的判断标准是：如果用户在 Google 日历里改了一个标题，你的 App 里"必须"在 1 分钟内跟上吗？如果答案是"第二天跟上也行"，那 A 档 + 每小时增量拉取就够了，别给自己上 C 档。

另外一个前置决策是先做哪一家。Google Calendar API v3 和 Microsoft Graph 在概念上几乎一一对应（增量 token、推送订阅、删除标记），但细节处处不同。建议先完整做透一家（推荐 Google：文档最全、沙盒最好搭），抽象出"同步引擎"接口后再接第二家——本文的架构图就是按这个思路画的，引擎层与厂商 API 之间隔一层适配器。

二、OAuth：scope 能小就小，token 当密码存

日历集成的第一道门是 OAuth，而这里的坑不在代码，在权限范围和合规。

Google 侧最常用的两个 scope：

https://www.googleapis.com/auth/calendar.readonly  # 只读：A 档够用
https://www.googleapis.com/auth/calendar.events      # 读写事件：B/C 档
# 不要用 https://www.googleapis.com/auth/calendar（整库读写，含设置），除非你真的要改日历本身

Outlook（Microsoft Entra ID）侧对应的是：

Calendars.Read        # 只读
Calendars.ReadWrite   # 读写事件
# 委托权限（用户登录授权）优先；应用权限需要管理员同意，且不能用于 /me/events 订阅

三条铁律：

1. scope 最小化，且授权页要诚实。日历类 scope 在 Google 属于受限范围（restricted），生产环境上线前必须完成 OAuth 验证，包含第三方安全评估——这一步经常要数周，立项第一天就去排队，别等到上线前一周才发现。另外，只读场景就别申请读写 scope：用户在授权页看到"查看、修改你的日历"时的流失率，和只看到"查看"时完全不是一个量级。

2. refresh token 必须加密存储，且做好轮换。access token 只有 1 小时寿命，后台同步靠的是 refresh token。把它当密码存：落库前用 KMS/密钥加密，绝不打进日志。Google 侧注意两点：同一用户同一 client 的 refresh token 有数量上限（超了最早的会被吊销），以及用户在 Google 账号页手动"移除访问权限"后，你的下一次刷新会直接失败——这必须当成"用户断开连接"事件处理，而不是重试三次再报错。

3. 断开即删数据。用户在你的 App 里点"断开日历连接"，或者 refresh 失败判定为撤销授权时，同步引擎要做三件事：停掉该用户的推送订阅/watch channel、删掉本地镜像的日程数据（或至少标记为不可用）、记一条审计日志。这是合规红线，也是拿回用户信任最便宜的方式。

// token 刷新失败的分类处理（伪代码，Google / Outlook 通用）
async function refreshAccessToken(user) {
  try {
    return await oauth2.refresh(user.encryptedRefreshToken);
  } catch (err) {
    if (err.code === 'invalid_grant') {
      // 用户撤销授权或 token 被吊销：不是"重试"，是"断开"
      await handleDisconnect(user, 'user_revoked');
      return null;
    }
    throw err; // 网络抖动等，走指数退避重试
  }
}

三、Google 增量同步：syncToken 是唯一的真相来源

Google Calendar API v3 的增量同步围绕一个不透明字符串 syncToken 设计。流程是：第一次调用 events.list 时不带 syncToken（做全量），响应里会带回 nextSyncToken；把它存下来，下次调用时带上，Google 只返回这期间变更过的事件，并给出新的 nextSyncToken。整个同步状态就是这一个字符串——丢了它，就等于从头再来。

// Google 增量同步主循环（Node.js + googleapis）
async function incrementalSync(user, calendarId = 'primary') {
  let syncToken = await db.getSyncToken(user.id, calendarId); // 可能为 null
  let pageToken = null;

  do {
    const params = {
      calendarId,
      singleEvents: true,   // 周期事件展开成实例：全量和增量必须保持一致！
      showDeleted: true,    // 已删除的事件以 status=cancelled 返回，别漏
      maxResults: 250,
      ...(syncToken ? { syncToken } : {}),
      ...(pageToken ? { pageToken } : {}),
    };
    let res;
    try {
      res = await calendar.events.list(params);
    } catch (err) {
      if (err.code === 410) {
        // syncToken 过期（Google 会定期作废旧 token）：唯一正确动作是全量重扫
        await db.clearSyncToken(user.id, calendarId);
        return fullSync(user, calendarId);
      }
      throw err;
    }
    for (const ev of res.data.items ?? []) {
      await applyEvent(user, ev); // 见第六节：映射 + 墓碑
    }
    pageToken = res.data.nextPageToken ?? null;
    if (!pageToken && res.data.nextSyncToken) {
      // 只有翻完所有页，nextSyncToken 才有效——提前存会导致丢事件
      await db.saveSyncToken(user.id, calendarId, res.data.nextSyncToken);
    }
  } while (pageToken);
}

三个坑点，个个都真实踩过：

1. singleEvents 必须全程一致。全量时用 singleEvents=true（周期事件展开成一个个实例），增量时就必须也是 true；混用会导致 Google 认为你在换查询条件，直接 410。选哪边取决于你的数据模型（见第六节），但选定就别改。

2. 410 不是错误，是信号。syncToken 会过期（Google 不承诺有效期），收到 410 后的标准动作是：清掉旧 token、做一次全量、存新 token。把 410 当异常告警的人，半夜会被 PagerDuty 叫醒很多次——把它当成正常分支写进代码。

3. nextSyncToken 必须翻完页再存。分页没走完就存 token，下一轮增量会从中间开始，中间页的事件就永远丢了。循环条件是 nextPageToken，存 token 的时机是"没有下一页了"。

四、Google 推送：watch channel 只负责"喊一声"

增量拉取解决"怎么高效地问"，推送解决"什么时候问"。Google 的 events.watch 会在日历变化时往你的 HTTPS 地址 POST 一个通知——但注意：通知里没有任何事件数据，只有几个 X-Goog-* 头（channel id、resource id、resource state）。收到推送后的唯一正确动作是：回头调用第三节的增量同步去拉。把推送当触发器、把拉取当真相来源，这就是架构图里那句铁律的由来。

// 建立 watch channel（每个日历一个 channel）
const { v4: uuid } = require('uuid');
async function createWatchChannel(user, calendarId = 'primary') {
  const channelId = uuid(); // channel id 必须全局唯一，建议 UUID
  const res = await calendar.events.watch({
    calendarId,
    requestBody: {
      id: channelId,
      type: 'web_hook',
      address: 'https://api.yourapp.com/webhooks/google-calendar',
      token: signChannelToken(user.id, calendarId), // 你自己的不透明串，防伪造用
      params: { ttl: '604800' }, // 秒；默认 604800（7 天），到期必须续
    },
  });
  // res.data.expiration：毫秒时间戳，存下来给续约 cron 用
  await db.saveChannel(user.id, calendarId, {
    channelId, resourceId: res.data.resourceId, expiration: res.data.expiration,
  });
}

// webhook 接收端（Express）
app.post('/webhooks/google-calendar', async (req, res) => {
  // 先 200，Google 不等你慢慢处理；处理放队列里异步做
  res.sendStatus(200);
  const channelId = req.header('X-Goog-Channel-Id');
  const channelToken = req.header('X-Goog-Channel-Token');
  const resourceState = req.header('X-Goog-Resource-State');
  if (resourceState === 'sync') return; // 建 channel 时的同步测试消息，忽略
  const binding = await db.findChannel(channelId);
  // 校验 token：对不上就丢弃——这是你的 webhook 唯一的身份验证
  if (!binding || !verifyChannelToken(channelToken, binding)) return;
  await syncQueue.push({ userId: binding.userId, calendarId: binding.calendarId });
});

推送侧的三个运营要点：

1. channel 会过期，必须续约。ttl 默认 7 天（604800 秒），到期 Google 不会提醒你——它只会安静地不再推送。正确姿势是一个每天跑的 cron：查出 48 小时内到期的 channel，用新的 channel id重新 watch（Google 要求 id 唯一，不能复用旧 id），成功后再停掉旧的。续约失败要告警，因为"推送悄悄停了"是最难察觉的故障。

2. 推送不可靠，轮询是安全网。Google 官方文档明确说推送不保证 100% 到达。所以架构上永远保留一条兜底：每 30–60 分钟对活跃用户跑一次增量拉取。推送是快车道，轮询是护栏，两条腿走路。

3. 地址必须是公网 HTTPS，且要能过 Google 的可达性校验。本地调试用 cloudflared/ngrok 起隧道（见第十一节）。另外 webhook 入口只做"验签 + 入队"，任何耗时逻辑都扔给队列 worker——Google 对响应超时很敏感，处理慢了会被判为投递失败。

五、Outlook 侧：delta query + change notification

Microsoft Graph 的概念和 Google 一一对应，只是名字不同：syncToken 对应 @odata.deltaLink，events.watch 对应 change notification 订阅。做过 Google 侧之后，Outlook 侧主要是"翻译"工作，但有几个独有坑点。

增量：calendarView/delta。注意 Outlook 用的是 calendarView/delta（时间窗口视图），而不是 events/delta——因为它直接返回展开好的实例，对做展示的 A 档特别友好：

// Outlook 增量同步：deltaLink 机制
async function outlookIncrementalSync(user) {
  let url = await db.getDeltaLink(user.id)
    ?? 'https://graph.microsoft.com/v1.0/me/calendarView/delta'
     + '?startDateTime=2026-01-01T00:00:00Z&endDateTime=2027-01-01T00:00:00Z';

  while (url) {
    const res = await graph.get(url); // 带上 access token
    for (const ev of res.value) {
      if (ev['@removed']) {
        await applyTombstone(user, ev.id, ev['@removed'].reason); // 删除墓碑
      } else {
        await applyEvent(user, ev);
      }
    }
    // 有 nextLink 说明还有页；只有拿到 deltaLink 才算"追上了"，这时才能存
    url = res['@odata.nextLink'] ?? null;
    if (!url && res['@odata.deltaLink']) {
      await db.saveDeltaLink(user.id, res['@odata.deltaLink']);
    }
  }
}

坑点：deltaLink 也会失效（比如用户很久没同步），失效时 Graph 会返回错误要求重新走完整 delta 流程——处理策略和 Google 的 410 一样：清掉旧 link，从头来一次。另外 @removed 只告诉你"删了"，不会告诉你删之前长什么样，所以墓碑表里至少要记外部 ID 和删除时间，方便审计和"撤销删除"的补偿逻辑。

推送：change notification 订阅。创建一个订阅分两步：先 POST /subscriptions，Graph 会立刻向你的 notificationUrl 发一个带 validationToken 的 GET 验证请求——你必须在几秒内原样返回这个 token（纯文本 200），订阅才算建成。这是很多人第一次对接失败的地方：验证请求走的是 GET、不是 POST，而且超时很短。

// 1) 创建订阅（事件资源官方上限约 7 天：10080 分钟）
POST https://graph.microsoft.com/v1.0/subscriptions
{
  "changeType": "created,updated,deleted",
  "notificationUrl": "https://api.yourapp.com/webhooks/outlook-calendar",
  "resource": "me/events",
  "expirationDateTime": "2026-10-25T16:00:00Z",  // ≤ now + 10080 分钟
  "clientState": "<你生成的随机串>"          // 每次通知原样带回，用来验真伪
}

// 2) 验证端点：收到 ?validationToken=xxx，原样返回
app.get('/webhooks/outlook-calendar', (req, res) => {
  if (req.query.validationToken) {
    res.set('Content-Type', 'text/plain');
    return res.status(200).send(req.query.validationToken);
  }
  res.sendStatus(400);
});

// 3) 通知接收：校验 clientState 后，只做"触发增量拉取"
app.post('/webhooks/outlook-calendar', async (req, res) => {
  res.sendStatus(202);
  for (const n of req.body.value ?? []) {
    if (n.clientState !== expectedClientState(n.subscriptionId)) continue; // 验伪
    if (n.lifecycleEvent === 'reauthorizationRequired') {
      await syncQueue.push({ type: 'resubscribe', subscriptionId: n.subscriptionId });
      continue;
    }
    // 通知体只有"变了"，没有"变成什么样"——回拉 delta 才是真相
    await syncQueue.push({ type: 'delta', userId: n.userIdHint });
  }
});

Outlook 推送的三个独有注意点：订阅续约用 PATCH /subscriptions/{id} 更新 expirationDateTime，建议在到期前 24 小时续；lifecycle 通知（如 reauthorizationRequired）是 Graph 告诉你"这个订阅快不行了"的官方通道，接住它比盲目定时续约更可靠；一个用户只建一个订阅，重复建订阅是被限流的最快方式。

六、数据模型：外部 ID 映射表 + 删除墓碑

同步引擎的核心是一张映射表。它回答三个问题：外部事件对应本地哪条记录？上次同步到哪了？删掉的东西怎么证明它删过？

-- external_events：外部日历事件 ↔ 本地事件的映射
CREATE TABLE external_events (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id       UUID NOT NULL REFERENCES users(id),
  provider      TEXT NOT NULL CHECK (provider IN ('google','outlook')),
  external_id   TEXT NOT NULL,          -- Google: event.id；Outlook: event.id
  local_id      UUID REFERENCES events(id),
  external_updated_at TIMESTAMPTZ,     -- 对方 updated 字段：冲突裁决用
  etag          TEXT,                  -- Google eTag：写回时做乐观并发
  deleted_at    TIMESTAMPTZ,           -- 墓碑：非空 = 对方已删
  UNIQUE (user_id, provider, external_id)
);
-- sync_state：每个用户的同步游标
CREATE TABLE sync_state (
  user_id UUID, provider TEXT, calendar_id TEXT,
  cursor TEXT,            -- Google: syncToken；Outlook: deltaLink
  cursor_updated_at TIMESTAMPTZ,
  channel_id TEXT, channel_expires_at TIMESTAMPTZ,  -- 推送订阅续约用
  PRIMARY KEY (user_id, provider, calendar_id)
);

周期事件怎么存？Google 把周期会存成一条带 RRULE 的父事件（instances 通过 recurringEventId 关联），Outlook 则是 seriesMaster + occurrences。两种策略：A/B 档建议存展开后的实例（查询简单，和 singleEvents=true / calendarView 天然对齐）；C 档如果要做"修改单次 vs 修改全系列"的写回，才需要存父事件 + 例外实例。选了展开策略，就要在写回时做反向聚合——这是 C 档最磨人的部分，也是"能用 B 就别上 C"的又一个理由。

删除必须走墓碑，不能硬删。对方删了一个会，你的库里如果直接 DELETE，下次全量重扫时你会以为"这是个新事件"吗？不会——因为全量里已经没有它了。但墓碑的真正价值在排障和审计："用户说上周三的会在 App 里消失了"，有墓碑你能回答"10 月 14 日 09:02 从 Google 侧删除同步过来"，没墓碑你只能 shrug。墓碑保留 90 天后归档，见《数据归档指南》的思路。

七、冲突解决：先定裁决规则，再写代码

双向同步里，冲突不是"会不会发生"，而是"什么时候发生"：用户在 Google 日历里改了会议时间，同时在你的 App 里改了会议地点，两次同步在窗口期内相遇了。没有裁决规则的代码，遇到冲突只能二选一瞎猜。

给独立开发者的实用裁决阶梯（按推荐度排序）：

1. 时间戳 LWW（Last-Write-Wins）：比较双方的 updated 时间戳，新的覆盖旧的。实现最简单，对 95% 的个人日程场景够用。注意时钟 skew：永远用对方 API 返回的 updated，不要用你收到推送的时间——后者是你的时钟，前者是真相。

2. 字段级合并：时间字段以日历侧为准、描述/备注以 App 侧为准。适合"两边各管一摊"的产品语义，但要写清楚字段归属表，否则半年后没人记得为什么地点总被覆盖。

3. 弹给用户：检测到双边都在同步窗口内改过同一事件，标记为冲突态，在 UI 里让用户二选一。这是 Notion / Linear 级产品的标准答案，但对小团队意味着一套冲突 UI + 状态机——除非冲突真的高频，否则 LWW + 变更通知（"你 App 里的修改被 Google 侧覆盖了"）更划算。

// LWW 裁决：Google 侧事件 vs 本地镜像
async function resolveConflict(local, remote) {
  const remoteUpdated = new Date(remote.updated);          // 对方真相时钟
  const localUpdated = local.external_updated_at;          // 上次同步时对方的时间
  const localDirty = local.local_updated_at > local.last_synced_at; // 本地是否改过
  if (!localDirty) return { action: 'apply_remote' };
  if (remoteUpdated <= localUpdated) return { action: 'push_local' }; // 对方没变，写回去
  // 双边都变了：LWW
  return remoteUpdated > local.local_updated_at
    ? { action: 'apply_remote', notify: 'local_overwritten' }
    : { action: 'push_local', notify: 'remote_overwritten' };
}

写回侧还有一个并发保护：Google 支持用 eTag 做乐观并发（If-Match），Outlook 则建议在更新前重读一次做 compare-and-swap。vibe 项目做到"写回走队列 + 单用户串行"就已经超过及格线了——同一个用户的写操作排成队，能消掉一大半竞态。

八、时区：同步视角的三个坑

（显示层的时区问题——"几点显示"——请看《日历预约实战指南》的时区三铁律。这里只讲同步时"怎么存才不丢信息"的坑。）

1. 原样存下对方的 timeZone，别转成 UTC 就扔。Google 事件的 start: { dateTime, timeZone } 里，timeZone 是"创建者当时的意图"（"北京时间早上 9 点开会"）。你转成 UTC 存没问题，但必须把原始 timeZone 也存下来——夏令时切换时，UTC 时间会漂，意图不会。

2. 全天事件没有时间。Google 全天事件用 start.date: "2026-10-20"（没有 dateTime），Outlook 用 isAllDay: true。把它当成带时间的事件解析，是"全天事件差一天" bug 的标准成因。数据模型里全天事件单独一个布尔字段，别和时间戳混在一起。

3. 周期事件的实例时区会变。一个每周例会，创建时是北京时间，夏令时切换后某些实例的 UTC 偏移会变。如果你存的是展开实例，每次增量同步都要以对方返回的实例时间为准，不要自己拿 RRULE 去算——让 Google/Outlook 做日历数学，你只做搬运。

九、配额、退避与批量：别在用户量涨起来那天翻车

日历 API 的配额是"平时无感、爆量致命"型。Google Calendar API 有按项目/按用户的速率限制，Graph 有更精细的 throttling（返回 429 + Retry-After）。三条保命策略：

1. 所有 API 调用走统一的限流器。按"用户"维度做令牌桶，而不是按进程——多实例部署时，进程级限流等于没限流。用 Redis 做分布式令牌桶，或者直接用 BullMQ 这类队列的 rate limiter（见《后台任务队列指南》）。

2. 429/5xx 一律指数退避 + 抖动。退避基数 1 秒、指数 2、加 20% 随机抖动、上限 5 分钟。Graph 明确返回 Retry-After 头时，听它的。把"收到 429 就降速该用户的同步频率"写成自动策略，而不是人工介入。

3. 用批量接口，但别滥用。Google 有 batch endpoint（一次 HTTP 请求塞多个 API 调用），适合"用户刚连上、第一次全量"的场景。但批量里的单个失败是 200 包错误体，要逐个检查——把 batch 当成"减少 TCP 往返"的优化，不是"绕过配额"的技巧。

十、合规与安全：上线前必须过的几道坎

1. Google OAuth 验证排队。日历 scope 是受限范围，生产环境需要完成 Google 的 OAuth 验证流程，包含第三方安全评估（CASA）。从提交到通过以"周"计，立项第一天就去 Google Cloud Console 提交。同时准备好隐私政策页和数据删除说明——审核员真的会点开看。

2. 最小权限 + 权限降级路径。如果你的产品后来发现"其实只读就够了"，要提供从 calendar.events 降级到 calendar.readonly 的路径：重新走授权、换 scope、清掉写回队列。scope 只升不降的产品，迟早在安全审计里被 challenge。

3. webhook 入口是公网入口。Google 侧靠 channel token、Outlook 侧靠 clientState + validation 握手。除此之外：验证端点和接收端点分开（GET 验证 / POST 接收）、对通知做去重（Google 可能重发）、记录所有 webhook 的来源 IP 段用于事后审计。不要在 webhook 里做重操作——它被打挂的那天，就是你同步停摆的那天。

4. 数据删除链路要真的走通。用户断开连接 → 停订阅 → 删本地镜像 → 删 token，四步要在一个事务性流程里完成，并且自己真的点一遍。审核和用户投诉时，"我们有删除按钮"和"删除真的删干净了"是两回事。

十一、测试：时间是最难 mock 的东西

日历同步的测试难点在于"时间"和"外部系统"：

1. 准备两个测试日历账号。Google 和 Outlook 各一个专用的测试账号，测试事件用固定前缀（如 [synctest]），CI 跑完自动清理。不要用个人主账号跑测试——某天 CI 把你的真实日程删了别怪我没提醒。

2. webhook 本地调试用隧道。cloudflared / ngrok 把本地 3000 端口暴露成公网 HTTPS，watch address 填隧道地址。注意隧道地址每次重启会变，写个脚本在启动时自动重建 watch channel。

3. 时间旅行测试。专门写几个用例：把系统时间调到 channel 过期前 1 小时（续约 cron 跑了吗？）、调到夏令时切换当天（周期事件实例时间对吗？）、制造一个 410（全量重扫走了吗？数据丢了吗？）。这三个用例能覆盖 80% 的线上故障。

4. 幂等性测试。对同一个事件连续 apply 三次，结果必须和一次一样。这是同步引擎的生命线——推送重发、轮询重叠、用户狂点"同步"按钮，都会制造重复投递。

十二、上线检查清单

发布前逐项打勾：

1. scope 是最小可用集合，授权页文案诚实
2. refresh token 加密存储，invalid_grant 走"断开"分支而非重试
3. Google：syncToken 翻完页再存；410 走全量重扫分支
4. Google：watch channel 有续约 cron（到期前 48 小时），channel id 每次用新的
5. Google：webhook 校验 X-Goog-Channel-Token，state=sync 的消息直接忽略
6. Outlook：deltaLink 只有拿到才存；@removed 走墓碑
7. Outlook：validationToken 验证端点是 GET 且秒回；clientState 每次通知都校验
8. Outlook：订阅有续约（到期前 24 小时）或接住 lifecycle 通知
9. 推送 + 轮询双轨：推送丢了，30–60 分钟轮询能兜住
10. 冲突裁决规则写进文档，LWW 用对方 updated 时间戳
11. 用户断开连接：停订阅、删镜像、删 token，一次点通
12. Google OAuth 验证已提交（或已通过），隐私政策页可访问

最后说一句大实话：日历同步是那种"调通只要一下午，稳定要三个月"的功能。它的复杂度不在 API 本身，而在状态——token 会过期、推送会丢、用户会撤销授权、夏令时会捣乱。把本文的同步引擎做成独立模块（Google/Outlook 各一个适配器 + 一套游标/墓碑/冲突逻辑），你会发现第二个日历厂商的接入成本只有第一个的三分之一。而这套"增量游标 + 推送触发 + 墓碑删除"的三件套，往后做邮件同步、文件同步、CRM 同步，思路是通的。