Ionic Capacitor本地通知schedule里at和on选项有什么区别？

二者绝非仅日期书写格式的区别，在调度逻辑、适用场景上有明确边界，结合给出的LocalNotificationSchedule接口定义拆解如下：

at 字段的行为逻辑 #

• 接收标准JS Date类型，是带毫秒精度的绝对时间锚点，代表“严格在某个确定的时间点触发通知”
• 搭配重复参数时的运行逻辑：以你传入的at时间为起始锚点，结合repeats、every定义的周期计算后续所有触发时间。比如设置at = new Date('2025-01-01T09:00:00')、every = 'day'，代表从2025年1月1日早上9点开始，每24小时触发一次通知。
• 最适合的场景：一次性倒计时提醒（比如设置2小时后触发会议提示）、需要严格对齐自定义起始时间的周期性提醒。

on 字段的行为逻辑 #

• 接收碎片化的时间维度配置对象，不需要传入完整Date实例，是基于日历规则的匹配式调度，系统会自动定位下一个符合配置规则的时间点触发。
• 不需要显式配置重复规则：它的重复逻辑完全由你填写的最高粒度时间字段决定——比如填{ year:2025, month:10, day:1, hour:9, minute:0 }，就只在2025年10月1日9点整触发一次；如果只填{ month:10, day:1, hour:9, minute:0 }，系统就会自动匹配每年10月1日9点触发，不需要额外加repeats或every参数。
• 最适合的场景：固定周期的常规提醒（比如每天早8点的喝水提醒、每月1号的账单提醒），完全不需要手动计算未来的绝对时间点。

为什么二者容易被混淆 #

很多场景下两种写法确实能跑出相似的最终效果：比如同样实现“每天早9点触发”，既可以算好明天9点的绝对时间，用at传对应Date对象搭配every: 'day'实现，也可以直接用on: {hour:9, minute:0}实现，但底层的可靠性差异很大：

基于at的周期调度把初始时间点当固定锚点计算周期，如果用户手动修改了系统时间、或者设备因为长时间休眠错过了首次触发的时间点，后续的排期很容易出现偏移甚至错过触发；
基于on的日历规则调度，是每次唤醒时都重新匹配符合规则的下一个时间点，就算系统时间跳变、设备长期休眠，通知排期也不会错乱。

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