微信小程序首次拒绝日历授权后，手动开启权限仍无法添加事件？

Question

微信小程序首次拒绝日历授权后，即使用户后续在系统设置中手动开启「日历」权限，调用 `wx.addPhoneCalendar` 仍可能返回 `fail:auth denied` 或静默失败。根本原因在于：微信小程序的授权状态缓存与系统权限不同步——`wx.getSetting()` 仅反映小程序本地授权记录（首次拒绝后永久标记为 `denied`），不会自动感知系统级权限变更；且该 API 不触发重新授权弹窗，无法通过 `wx.authorize` 主动刷新。开发者若未在调用前用 `wx.openSetting()` 引导用户二次确认，或未对 `scope.calendars` 状态做实时校验与兜底处理，将导致授权“假生效”。此问题高频出现在 iOS 系统（尤其 iOS 17+）及部分安卓定制 ROM 中，是典型的授权生命周期管理缺失所致。

Answer 1

```html

一、现象层：表象复现与典型错误日志

开发者在 iOS 17.4+ 或华为 EMUI 12/ColorOS 13 等定制 ROM 上复现如下链路：

1. 用户首次点击「添加日程」触发 wx.addPhoneCalendar → 弹出系统授权弹窗 → 用户点击「不允许」；
2. 用户退出小程序，手动进入「系统设置 → 微信 → 日历权限」开启开关；
3. 重新进入小程序，再次调用 wx.addPhoneCalendar → 返回 fail:auth denied 或无任何回调（静默失败）；
4. 调用 wx.getSetting({ withSubNVue: false }) 获取结果中 scope.calendars === 'denied'，且 authSetting['scope.calendars'] 恒为 false。

二、机制层：微信授权模型的三重隔离设计

该问题本质源于微信小程序运行时沙箱对权限状态的「三层缓存抽象」：

层级	数据源	更新时机	是否感知系统变更
① 小程序本地授权记录（getSetting）	微信客户端本地 SQLite 表	仅首次 authorize 或 openSetting 后写入	❌ 完全不监听系统级开关变化
② 系统原生权限状态（iOS/Android API）	Native OS Permission Manager	用户手动开关/系统策略变更	✅ 实时生效，但微信未桥接同步
③ 微信 SDK 内部状态机（addPhoneCalendar 调用路径）	内存态 flag + native bridge 校验	每次调用前仅查本地记录，不 re-check OS	❌ 绕过系统校验，直接拒绝

三、验证层：精准定位授权失步的关键代码路径

// ✅ 正确验证流程（必须组合使用）
async checkCalendarAuth() {
  const { authSetting } = await wx.getSetting();
  const scope = 'scope.calendars';
  
  if (authSetting[scope] === 'authorized') {
    return true;
  } else if (authSetting[scope] === 'denied') {
    // ⚠️ 注意：此处不能直接 assume 系统关闭！需二次探测
    const systemStatus = await this.probeSystemCalendarPermission(); // 自定义 Native 插件或 H5 fallback
    if (systemStatus === 'granted') {
      wx.showModal({
        title: '权限已开启',
        content: '请通过「设置」重新授权以同步状态',
        confirmText: '去设置',
        success: () => wx.openSetting({}) // 必须触发 openSetting 才能刷新本地缓存
      });
    }
  }
  return false;
}

四、架构层：授权生命周期管理缺失的系统性风险

下图展示授权状态在用户行为、系统变更、小程序逻辑间的异步漂移过程：

graph LR
  A[用户首次拒绝] --> B[wx.getSetting 缓存 scope.calendars=denied]
  C[用户系统设置开启日历] --> D[OS 权限状态变为 granted]
  B -->|微信未监听| E[getSetting 仍返回 denied]
  D -->|微信未桥接| E
  E --> F[addPhoneCalendar 直接 fail:auth denied]
  G[调用 wx.openSetting] --> H[触发微信重读 OS 状态并更新本地缓存]
  H --> I[后续 getSetting 返回 authorized]

五、方案层：生产环境可落地的四级防御体系

1. 前置探测：在关键入口页（如日程页 onLoad）预检 wx.getSetting 并标记状态；
2. 动态兜底：对 addPhoneCalendar 的 fail 回调增加 if (err.errMsg.includes('auth denied')) 分支；
3. 强制同步：失败后立即调用 wx.openSetting({ withSubNVue: false }) 并监听 success 回调中的新 setting；
4. 降级通道：集成 H5 日历导出（.ics 文件下载）或短信提醒作为 iOS/Android 权限不可用时的业务保底。

六、演进层：面向未来的兼容性增强建议

针对 iOS 17+ 的 AppTrackingTransparency 变更与 Android 14 权限细化趋势，建议：

• 将 scope.calendars 纳入小程序「权限健康度监控」埋点，统计 getSetting !== systemStatus 的偏差率；
• 在基础库 3.4.0+ 中启用 openSetting 的 withSubNVue 参数（需适配新版调试器）；
• 与微信开放平台保持同步，关注 authorize 文档更新 中关于 scope.calendars 的特殊说明（当前仍标注为「暂不支持重新授权」，需以 openSetting 替代）。

七、避坑层：被低估的三个高危实践

1. 误用 wx.authorize({scope: 'scope.calendars'}) —— 该 API 对日历权限无效，调用即报错 scope not supported；
2. 依赖 getSetting 单次结果做长期缓存（如 Storage 存储 authSetting），导致状态陈旧；
3. 在 openSetting success 回调中未再次调用 getSetting 刷新状态，造成「用户已同意但代码仍走拒绝分支」。

```