改期后的.ics文件，如果事件身份变了，可能新增第二条预约而非更新原来那条。增加日历下载前，应约定UID与版本策略。这是导出身份问题，与时区解析或可用名额分开。
适用读者与交付决定
提供日历导出的咨询及活动企业。把本题作为网站供应方的有限验收任务；实际系统证据不能由教学例子替代。
官方依据与解释边界
iCalendar定义持久组件身份UID及版本信息SEQUENCE；真实导入更新仍取决于日历客户端和发送流程。 RFC5545: iCalendar · 核对日期：2026年10月16日。
已填写教学例子
合成例子，不是真实客户案例。 列出有限输入、预期结果及反例，不代表已完成真实平台集成。
窄屏可横向滚动表格。
| 输入／情况 | 检查口径 | 预期结果 |
|---|---|---|
| UID=A seq1 → UID=A seq2 | 同身份较新版本 | 更新候选 |
| UID=A → UID=B | 身份不同 | 新事件风险 |
| UID=A seq2 → seq1 | 较旧版本 | 旧版本复核 |
怎样执行验收
- 分配稳定合成事件ID并批准版本递增规则。
- 在获准测试流程导出初版、变更与取消情况。
- 在支持客户端导入，记录更新原事件还是新建事件。
如何解释结果与保留证据
有限函数只比较身份和版本，不生成完整合法ICS或执行日历传输。比较正确，也不保证客户端合并手工导入。验收应保留日历应用版本、导入文件与真实事件数量。
适用边界
不覆盖时区、邀请安全、重复事件例外或真实预约，不访问日历或发送邀请。
离线复核
把下方两份文件存入同一目录，以Node22.13或更新版本运行。示例不联网、不修改任何账号或网站。 已填输入与预期输出 · 可检查的函数
node decision-check.mjs calendar-export-event-identity.json