企业官网建设流程全解析

最近接了个需求：用户在App里输入一个日历订阅地址（.ics链接），我们把远端订阅内容拉下来，解析成一条条日程事件，写进Android系统日历，用户打开自带日历就能看到，而且订阅源更新后App可以主动刷新。

需求听起来不算复杂，但真正动手后才发现，日历订阅解析这件事，每一步都比想象中深。ICS格式的语法细节、时区问题、重复规则（RRULE）的方言差异、系统日历写入的权限和字段限制，任何一个环节没处理好，轻则用户看到错误时间，重则事件重复、提醒丢失、日历残留垃圾数据。

这篇文章把我完整踩过一遍的方案整理出来，工程用到的代码片段会直接放出来，包括常规文档里不会写的注意事项，适合正在做类似功能的Android开发同学参考。

先说结论：如果你只是想在App内展示订阅日程，不进系统日历，那直接拉取ICS文本、解析VEVENT列表就够了，这部分很轻。如果目标是“同步到系统日历”，那就绕不开CalendarContract，而它和你从订阅文件里读到的东西之间，并不是一一对应的关系。整篇按实际开发链路来写，从网络拉取到最终落到系统日历，每一环都会交代为什么这么做。

1. 业务场景与整体数据流：日历订阅到底在解决什么问题

1.1 典型应用场景

日历订阅最常见的应用场景，是那些“日程不由用户自己创建，而是由某个组织方统一维护”的场景。

比如学校每周发布的课程表，发一个订阅链接，学生订阅后就能在自己手机日历里看到每周上课安排；比如球队/社团的赛程赛历，主办方更新一个比赛时间，所有粉丝的日历自动同步；再比如企业内部排班系统、健身房课程表、甚至个人付费订阅的“冥想打卡计划”，本质都是同一个套路。

提供方在服务端维护一个ICS文件，订阅方定期拉取。双方不需要单独开发接口，格式是开放标准，任何客户端都能解析。这在服务端成本上几乎为零，对客户端来说却是标准的“前端吃复杂度”的活。

1.2 整条链路的五个环节

我把整个功能拆成五个环节：

1. 拉取：从订阅URL下载ICS文本。
2. 解析：把ICS文本变成内存中的事件对象。
3. 映射：把解析出来的模型转换成系统日历要求的ContentValues。
4. 写入：通过CalendarContract插入/更新/删除系统日历事件。
5. 同步：处理订阅源的增量更新和失效清理。

这里最关键的一点是：解析出来的事件模型和系统日历要求的内容模型，并不完全一致。

比如ICS里一个事件可以被EXDATE排除了某一天，但系统日历的Events表里根本没有EXDATE字段；比如ICS里的RRULE和Android日历的RRULE虽然都叫RRULE，但细节上有差异；再比如ICS里没有指定TZID的事件到底是UTC还是本地时间，语义和系统日历的EVENT_TIMEZONE字段完全不同。

这些差异就是坑的来源。所以我在项目里做的第一件事，不是急着写拉取代码，而是先定义一个统一的日历事件模型。

1.3 先定义一个统一的事件模型

解析库的输出先转换成我们自己的模型，后续写入和同步逻辑只跟这个模型打交道，这样以后换解析库、换订阅源，都不至于牵连全局。

data class SubscriptionEvent( val uid: String, // 事件唯一ID，幂等更新的关键 val title: String?, // SUMMARY val description: String?, // DESCRIPTION val location: String?, // LOCATION val startMillis: Long, // 开始时间（已转为毫秒） val endMillis: Long, // 结束时间 val allDay: Boolean = false, // 是否全天事件 val timeZoneId: String? = null, // 事件时区，如 Asia/Shanghai val rrule: String? = null, // 重复规则原文 val excludedDates: List<Long> = emptyList(), // EXDATE解析结果 val reminderMinutes: List<Int> = emptyList(), // 提醒提前分钟数 )

有了这个模型，后面的逻辑就清晰了：解析器负责把任意ICS塞进这个模型，写入器负责把这个模型塞进系统日历，两者互不关心。

2. ICS格式拆解：先读懂订阅文件的“语法”

2.1 VCALENDAR的骨架

ICS文件本质上是一个纯文本文件，核心语法是“属性:值”加“组件”的嵌套结构。一个最典型的订阅文件长这样：

BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp//CalDAV Client//EN BEGIN:VTIMEZONE TZID:Asia/Shanghai BEGIN:STANDARD DTSTART:19910101T000000 TZOFFSETFROM:+0800 TZOFFSETTO:+0800 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:event-20250101-001@example.com DTSTAMP:20250101T000000Z DTSTART;TZID=Asia/Shanghai:20250101T090000 DTEND;TZID=Asia/Shanghai:20250101T100000 SUMMARY:周例会 LOCATION:线上会议室A DESCRIPTION:每周产品迭代同步会 RRULE:FREQ=WEEKLY;BYDAY=MO;UNTIL=20251231T010000Z BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:会议提醒 END:VALARM END:VEVENT END:VCALENDAR

顶层是VCALENDAR组件，里面可以包含多个VTIMEZONE和VEVENT。VTIMEZONE提供时区定义，VEVENT是真正的日程事件。

解析时最常见的误区是：只盯着VEVENT看，忽略VTIMEZONE。如果订阅文件里的DTSTART带有TZID参数，但这个TZID没有对应的VTIMEZONE定义，很多时候解析器也能正常返回一个时区ID，但要小心这个ID可能是“猜测”的结果。严谨做法是解析时把TZID和VTIMEZONE对应起来验证一次，后面写入系统日历才不容易错。

2.2 VEVENT里哪些属性是必须处理的

一个VEVENT里可能出现的属性很多，但工程上真正需要处理的就这几个：

DTEND和DURATION要注意：有的订阅源用DTEND，有的用DURATION（比如PT1H表示持续1小时）。写统一模型时，要把DURATION转成实际的endMillis，而不是把DURATION原文存进去。

2.3 解析前必须处理的三类语法细节

第一，行折叠。RFC5545规定ICS每行不能超过75个八位字节，超长的行会被拆成多行，续行以空格或制表符开头。解析前必须先把折叠恢复，否则一个很长的DESCRIPTION会被拆成好几行，直接按行解析会丢内容。

恢复逻辑很简单：

fun unfoldIcsLines(text: String): List<String> { val lines = text.replace("\r\n", "\n").split("\n") val result = mutableListOf<String>() var current = StringBuilder() for (line in lines) { if (line.isEmpty()) continue if (line[0] == ' ' || line[0] == '\t') { current.append(line.substring(1)) } else { if (current.isNotEmpty()) { result.add(current.toString()) } current = StringBuilder(line) } } if (current.isNotEmpty()) result.add(current.toString()) return result }

第二，转义字符。在文本值（比如SUMMARY、DESCRIPTION）里，逗号、分号、反斜杠、换行都会被转义。逗号容易被人忽略，因为它在RRULE里是正常分隔符，在文本里却必须写成“,”。解析时如果不反转义，一个标题“产品评审,需求同步”会被错误截断。反转义顺序有讲究：先处理“\”，再处理“,”“;”“\n”，顺序反了会出现二次转义问题。

第三，属性参数。DTSTART;TZID=Asia/Shanghai:20250101T090000 这种带参数的形式非常常见。解析时不能只取冒号后面的时间字符串，必须同时读参数里的TZID和VALUE。VALUE=DATE表示这是一个全天事件，时间字符串只有日期没有时分秒，必须单独区分。

3. 解析器选型：别一上来就自己写

3.1 为什么默认推荐成熟解析库

ICS格式的坑集中在语法层面，自己写解析器很容易漏。行折叠、转义、参数、时区定义、RRULE的各种组合，覆盖全了要花不少时间。

我在项目里对比过几个方案：

biweekly是目前Android端比较顺手的选择，它对RFC5545的覆盖度够用，解析和序列化都支持，还能直接读RRULE做日期展开。如果你只是要“拉个订阅地址、读几个VEVENT”，它不会让你引入一堆没用的类。

3.2 实际接入代码

用biweekly解析ICS文本，核心代码很简短：

import biweekly.Biweekly; import biweekly.ICalendar; import biweekly.component.VEvent; import java.util.List; List<ICalendar> calendars = Biweekly.parse(icsText).all(); for (ICalendar calendar : calendars) { for (VEvent event : calendar.getEvents()) { String uid = event.getUid() != null ? event.getUid().getValue() : ""; String summary = event.getSummary() != null ? event.getSummary().getValue() : ""; String location = event.getLocation() != null ? event.getLocation().getValue() : ""; String description = event.getDescription() != null ? event.getDescription().getValue() : ""; Date start = event.getDateStart() != null ? event.getDateStart().getValue() : null; Date end = event.getDateEnd() != null ? event.getDateEnd().getValue() : null; RecurrenceRule rrule = event.getRecurrenceRule() != null ? event.getRecurrenceRule().getValue() : null; } }

需要注意：biweekly的getDateStart().getValue()返回的是Date，但它的时区语义跟Android的TimeZone不一定是同一套。取出来后要做一次规范化，比如统一转成UTC毫秒值，或者显式记录event.getDateStart().getTimezone()返回的时区ID，再丢进模型。

拉取那一步也提醒一句，HTTP请求建议带上Accept头：

Request request = new Request.Builder() .url(subscriptionUrl) .header("Accept", "text/calendar, application/ics;q=0.9, */*;q=0.5") .build();

有些服务端会根据Accept头返回不同格式，不声明的可能拿到HTML错误页。

3.3 手写解析器什么时候够用

如果订阅源是自家后端控制的，格式固定、字段有限，就只需要SUMMARY、DTSTART、DTEND、UID这几个属性，手写解析器完全能应付。这种情况下用一个成熟解析库反而显得重。

但手写解析器必须在代码里明确处理三个问题：折叠恢复、转义反转、全大写属性和参数解析。哪怕格式再固定，这三样也一定会遇到。我见过一个简化的手写方案，直接按行找“BEGIN:VEVENT”和“END:VEVENT”之间的内容，再用冒号split出属性名和值，不处理折叠，结果描述文本一超过75个字符就被截断，用户看到的是半句话。

所以我的建议是：能用库就用库，库覆盖不了的特殊订阅源（比如有时间窗限制的动态订阅）再手写，并且手写时把上面三个通用问题一次性处理掉。

4. 写入系统日历：CalendarContract的正确用法

4.1 权限与账号准备

写入系统日历前，需要在AndroidManifest里声明权限：

<uses-permission android:name="android.permission.READ_CALENDAR" /> <uses-permission android:name="android.permission.WRITE_CALENDAR" />

而且这两个权限是运行时权限，必须在运行时动态申请。很多同学漏了READ_CALENDAR，只申请WRITE_CALENDAR，结果在部分机型上写入没问题，读取查询的时候闪退，因为查询Events表需要READ权限。

权限拿到后，还要保证有一个“日历账号”。系统日历里的所有事件都归属于某个日历（Calendar），没有日历就插不进去。

通常有两条路：一是直接使用系统默认日历，简单但会把事件混进用户自己的日历里，不便于后续批量清理；二是创建自己的日历账号，这样订阅任务的事件都归在一个独立日历下，更新、删除、清理都方便，也不会污染用户个人日程。

创建日历的代码：

fun createCalendarIfNeeded(context: Context): Long { val calendars = context.contentResolver.query( CalendarContract.Calendars.CONTENT_URI, arrayOf(CalendarContract.Calendars._ID), "${CalendarContract.Calendars.ACCOUNT_NAME}=? AND ${CalendarContract.Calendars.ACCOUNT_TYPE}=?", arrayOf(CALENDAR_ACCOUNT_NAME, CALENDAR_ACCOUNT_TYPE), null ) calendars?.use { cursor -> if (cursor.moveToFirst()) return cursor.getLong(0) } val values = ContentValues().apply { put(CalendarContract.Calendars.ACCOUNT_NAME, CALENDAR_ACCOUNT_NAME) put(CalendarContract.Calendars.ACCOUNT_TYPE, CALENDAR_ACCOUNT_TYPE) put(CalendarContract.Calendars.NAME, "订阅日程") put(CalendarContract.Calendars.CALENDAR_DISPLAY_NAME, "日历订阅") put(CalendarContract.Calendars.CALENDAR_COLOR, 0xFF4CAF50.toInt()) put(CalendarContract.Calendars.CALENDAR_ACCESS_LEVEL, CalendarContract.Calendars.CAL_ACCESS_OWNER) put(CalendarContract.Calendars.VISIBLE, 1) put(CalendarContract.Calendars.SYNC_EVENTS, 1) } val uri = context.contentResolver.insert( CalendarContract.Calendars.CONTENT_URI, values ) return uri?.lastPathSegment?.toLong() ?: -1L }

这里ACCOUNT_TYPE我习惯用自定义常量，比如包名加后缀，这样等于在系统日历里注册了一个属于自己的账号空间。不同机型对CalendarContract.Calendars.CONTENT_URI的写入限制不太一样，个别设备要求必须先有账号，实战中遇到插入返回null的情况，可以退回使用系统默认日历ID。

4.2 插入与更新事件

插入事件最核心的字段是DTSTART、DTEND和EVENT_TIMEZONE。很多坑都出在这三个的组合上。

val values = ContentValues().apply { put(CalendarContract.Events.CALENDAR_ID, calendarId) put(CalendarContract.Events.TITLE, event.title ?: "") put(CalendarContract.Events.DESCRIPTION, event.description ?: "") put(CalendarContract.Events.EVENT_LOCATION, event.location ?: "") put(CalendarContract.Events.DTSTART, event.startMillis) put(CalendarContract.Events.DTEND, event.endMillis) put(CalendarContract.Events.EVENT_TIMEZONE, event.timeZoneId ?: TimeZone.getDefault().id) put(CalendarContract.Events.RRULE, event.rrule) put(CalendarContract.Events.UID_IDENTIFIER, event.uid) put(CalendarContract.Events.STATUS, CalendarContract.Events.STATUS_CONFIRMED) } val uri = context.contentResolver.insert(CalendarContract.Events.CONTENT_URI, values) val eventRowId = uri?.lastPathSegment?.toLong() ?: -1L

EVENT_TIMEZONE非常关键。ICS里如果DTSTART带TZID=Asia/Shanghai，那么event.timeZoneId就是Asia/Shanghai，写入时这个字段就置为Asia/Shanghai。如果ICS里DTSTART没带TZID且是一个LOCAL时间，理论上表示“在事件发生地点的本地时间”，但Android系统日历内部必须指定一个解释这个时间的时区，所以这种情况下我统一用TimeZone.getDefault().id来兜底。

另外要注意：如果ICS里DTSTART是一个UTC时间，字符串结尾带Z，比如“20250101T010000Z”，解析后通常已经转成了UTC毫秒值，此时timeZoneId应该传“UTC”，而不是用户本地时区，否则系统会再做一次本地时区的偏移换算，事件时间就错了一截。

4.3 全天事件和提醒的特殊处理

全天事件的ICS写法是“DTSTART;VALUE=DATE:20250101”，只有日期，没有时分秒。映射到SubscriptionEvent时，allDay被置为true，插入系统日历的ContentValues也要做对应处理：

if (event.allDay) { values.put(CalendarContract.Events.ALL_DAY, 1) values.put(CalendarContract.Events.DTSTART, startMillisAtMidnight) values.put(CalendarContract.Events.DTEND, endMillisAtMidnight) values.put(CalendarContract.Events.EVENT_TIMEZONE, TimeZone.getDefault().id) }

全天事件的DTSTART在ICS里是“00:00:00”的本地日期，但到了系统日历里要以毫秒值表示，而且ALL_DAY=1时系统对时区的解释逻辑不同。我踩过的坑是：直接把解析出来的00:00 UTC毫秒塞给DTSTART，没有把日期转成本地时区的零点，结果用户看到的是“前一天下午4点”开始的假全天事件。

提醒的插入则要等事件插入成功之后，拿到eventRowId再操作：

event.reminderMinutes.forEach { minutes -> val reminder = ContentValues().apply { put(CalendarContract.Reminders.EVENT_ID, eventRowId) put(CalendarContract.Reminders.MINUTES, minutes) // 0表示准时，-1表示不提醒 put(CalendarContract.Reminders.METHOD, CalendarContract.Reminders.METHOD_ALERT) } context.contentResolver.insert(CalendarContract.Reminders.CONTENT_URI, reminder) }

VALARM里的TRIGGER通常是“-PT15M”这种ISO 8601格式，表示事件开始前15分钟，解析时要转成分钟数。一个事件可能有多条提醒，注意别用覆盖式写入，要逐条插入Reminders表。

4.4 幂等更新：防止重复的完整策略

日历订阅的同步核心是“幂等”：同一个UID的事件，更新的时候不能变成两条重复事件。

我采用的策略是：以UID_IDENTIFIER为唯一键，在写入前先查一次。

fun findEventByUid(context: Context, calendarId: Long, uid: String): Long? { val projection = arrayOf(CalendarContract.Events._ID) val selection = "${CalendarContract.Events.CALENDAR_ID}=? AND ${CalendarContract.Events.UID_IDENTIFIER}=?" val args = arrayOf(calendarId.toString(), uid) context.contentResolver.query( CalendarContract.Events.CONTENT_URI, projection, selection, args, null )?.use { cursor -> if (cursor.moveToFirst()) return cursor.getLong(0) } return null }

如果查询到了，就更新这条事件；否则插入。UID为空的情况，我会生成一个UUID放进去，保证同步逻辑永远有唯一键可用。

全量同步时更省事的方法是：先查出该日历账号下的所有事件，跟本次订阅解析出来的UID集合做差集，差集部分就是应该删除的。做这个操作时要注意，只删除我们创建的账号下的事件，绝不要按用户个人日历去删。有些实现图省事，把订阅源事件全删了再全插，如果中间用户手动改过某条事件，改的内容也会被删掉，体验很糟糕。

5. RRULE重复规则：这个字段的坑比想象中深

5.1 常见RRULE语义速查

RRULE是日历订阅里最体现标准复杂度的字段。常见写法：

系统日历的Events.RRULE字段可以直接接受这些规则，理论上我们只需要把从ICS解析到的RRULE字符串原样传给ContentValues就行。

但这里有个坑：Android系统日历的RRULE支持的是RFC2445/5545格式，很多云端日历服务生成的RRULE也许能显示，但个别厂商对某些规则的实现有差异，尤其是“FREQ=MONTHLY;BYDAY=2TU”这种“月内第几周的星期几”写法，部分设备会直接忽略或解析错误。

5.2 系统日历RRULE和订阅RRULE的方言差异

最典型的差异是UNTIL的语义。

ICS里UTC时间的UNTIL写作“UNTIL=20251231T010000Z”。但有些系统日历要求UNTIL的时间格式必须和DTSTART的时区一致，或者只支持UTC，不支持带TZID的本地时间。如果直接传抄，用户可能看到重复规则提前结束或延后结束。

实操建议：在写入系统日历前，把RRULE里的UNTIL统一转成UTC格式，并确保是Z结尾。如果原RRULE里没有UNTIL只有COUNT，那基本不用处理。另外，RRULE内部的逗号分隔符不要多加空格，有的实现很死板，“BYDAY=MO, WE, FR”带空格会解析失败。解析库输出一般没问题，但如果是手写拼接，务必检查。

5.3 EXDATE不支持的应对方案

系统日历的Events表没有EXDATE字段。而ICS里EXDATE很常见，含义是“按RRULE本该重复，但在这些日期不重复”。

比如每周一开会，但1月1日放假，RRULE照旧，EXDATE排掉这一天。如果不处理EXDATE，系统日历会在1月1日也生成一个事件。

三种方案：

1. 展开后逐条插入具体日期，跳过EXDATE。这是最准确但最耗事件的方案，重复N次就有N条记录，编辑哪条都只会改那一条，不同步。
2. 保留RRULE透传，但把EXDATE日期作为独立“缺席占位”处理——实际操作中往往是忽略，导致多显示一天。
3. 把运行期展开得到的实际实例按天插入，并保留一个“父事件UID”，让相关实例共享同一个UID前缀，便于后续更新。

我最终采用第3种的改良版：订阅里的重复事件，如果含EXDATE，就在本地展开RRULE，为每个实例生成一条系统日历事件，标题后缀带上“（第1期）”“（第2期）”之类的编号，方便用户区分。UID在原始UID基础上追加index后缀，保证每条实例都有独立ID，又保留原始UID用于规则变化的追踪。

如果订阅源没有EXDATE，我仍然优先透传RRULE，这样用户可以在系统日历里自由编辑某一次事件而不会影响整列，体验最好。

5.4 展开还是透传：两套方案对比

如果订阅源的事件重复次数很少（比如每周一次、持续半年），透传RRULE基本够用，遇到EXDATE的概率低，处理最简单。如果订阅源是复杂的课程表、排班表，EXDATE出现频率高（调课、放假、停课通知），那就得牺牲一点同步性能，选择本地展开。这个选择要在项目一开始就定下来，中途换方案会带来灾难性的数据迁移问题。

6. 实测最容易翻车的5个边界情况

6.1 没有TZID的事件被当作UTC

ICS规范里，没有TZID的DTSTART默认是“浮动时间”，即事件在本地时钟意义下发生，不绑定时区。但很多解析库在转成Date时，会默认按UTC解释。

例如DTSTART:20250101T090000，解析库可能返回“2025-01-01 09:00:00 UTC”，转成毫秒后，再写入系统日历并指定EVENT_TIMEZONE为本地时区，用户看到的就是本地时间9点。如果刚好解析库返回的是“LocalDateTime”且代码里又手动set了Timezone，就很容错乱。

我的统一处理规则：解析阶段一旦发现DTSTART没有TZID参数，就把它当作“本地浮动时间”，转成毫秒时使用TimeZone.getDefault()；如果带TZID参数，就用TZID转成UTC毫秒。两种情况明确分开，不要在写入阶段再做二次猜测。

6.2 全天事件的DATE格式

全天事件前面提过一次，这里再强调：DTSTART;VALUE=DATE:20250301表示“3月1日全天”，不是“3月1日 00:00 UTC”。

写入时如果只把这条字符串转成UTC毫秒，再扔进Events表且ALL_DAY=1，绝大多数设备会把事件显示成3月1日下午4点开始。正确的做法是先把DATE字符串按当地时区解析成0点毫秒（比如用Calendar.getInstance().set(year, month, day, 0, 0, 0)），再指定时区写入。

我自己做个一层防御：凡是DATE-only格式，先把字符串转成LocalDate，再用系统默认时区求毫秒，写入时显式带ALL_DAY=1和TimeZone.getDefault().id。

6.3 夏令时切换当天的偏移

如果用户所在地区有夏令时，订阅源又用了绝对UTC时间，夏令时切换当天的事件会整体偏移一小时。举个实际例子：某事件每周三10:00在瑞士举行，ICS里DTSTART;TZID=Europe/Zurich:20250305T100000，解析转成UTC毫秒后，冬天和夏天的UTC偏移不同，写入系统日历时如果事件时区没写对，用户就会遇到“这周三10点、下周三9点”的诡异情况。

解决办法只有一个：事件时区必须原样保留，不要想当然地把所有时间都转成用户本地时区再写入。订阅方用什么时区，Events.EVENT_TIMEZONE就填什么时区，让系统日历自己处理夏令时偏移。

6.4 增量更新时UID不稳定

理论上UID在事件的一生中应该保持不变。但现实中有些订阅源生成的UID里带时间戳，比如“event-1714567890@example.com”，每次更新事件时UID都会变。这就导致按UID做幂等同步时永远匹配不上，旧的删不掉，新的插进来，事件越积越多。

遇到这种情况，靠UID不靠谱，我的兜底策略是：按“标题+开始时间+日历账号”组合作为第二物理主键，查询时先按UID查，查不到再按组合键查，仍然查不到才插入。这样基本能兜住UID不稳定带来的重复问题。

6.5 权限被撤销后的残留垃圾

日历订阅同步还有一个容易被忽略的问题：用户可能在系统设置里撤销了日历权限，但App并不知道。下次同步时，WRITE_CALENDAR权限没了，插入操作直接抛SecurityException，但之前插入的事件还残留在系统日历里。

我现在的做法是：每次App启动和进入前台时检查日历权限，如果发现权限被撤销，提示用户并提供一个“清空本订阅日历”的按钮。清理代码就是删除我们创建的日历账号下所有事件：

val selection = "${CalendarContract.Events.CALENDAR_ID}=?" val args = arrayOf(calendarId.toString()) context.contentResolver.delete(CalendarContract.Events.CONTENT_URI, selection, args)

注意如果日历账号本身被用户删了，calendarId会失效，这时候要重新走一遍创建日历的逻辑。这个清理动作最好做成显式的，不要每次启动都自动删除，免得用户以为日历被弄坏了。

最后再分享一个小技巧：调试日历订阅解析时，别直接拿真实订阅源测，先用一个固定的小ICS文件在本地测通全链路，再换成真实订阅源。真实源不可控，可能随时改格式、加新字段，本地固定文件能帮你快速定位是自己解析逻辑变了，还是对方订阅内容变了。做日历订阅解析，稳定性和可排查性比“一次跑通”重要得多。