日历权限显示已授权，应用里还是旧日程或者少了几条事件，先别急着重装或反复点“刷新”。这类问题通常按四层核对顺序推进：授权的是哪一类日历访问、被读取的是哪个账户与分组、界面读的是本地缓存还是实时数据、改动是不是从另一台设备同步过来。每一层都留下可对比的记录，比笼统地说“权限给了”更能定位问题。下面按这个顺序给出检查动作、判定依据和下一步指向。
权限页显示“已授权”只说明应用拿到了某个级别的日历访问，不等于它读到了你期望的全部日历。适用场景是权限已开启但日程显示旧数据或漏事件；操作上先记录权限级别与已授权账户，再核对系统日历账户的同步开关和最近同步时间，然后用切换账户、重启应用、手动刷新对比显示，最后在另一台设备改一条事件记录到达时间。边界是：账户为只读或同步关闭时，应用侧怎么刷新都拿不到数据，需要先回到系统账户设置处理。
确认授权的是哪一类日历访问
日历权限通常不是一个二值开关。系统权限页里能选到的访问级别，以及允许应用访问的账户范围，会直接决定应用能读到什么。先把这三项抄下来，作为后面判断的基线：
- 权限级别：完整访问、仅添加事件、仅查看空闲/忙闲，还是“仅在使用时允许”。只读或仅添加的级别下，应用无法列出全部已有事件。
- 已授权账户：是全部日历，还是只勾了某一个账户或某一个分组。只勾部分账户时，页面里看不到其他账户的事件属于预期行为。
- 应用内可见范围：打开应用的日历列表或账户筛选，记下实际出现哪几个日历名称。
把权限页的记录和应用内可见的日历名称对齐。如果权限级别是只读或仅添加，先改成完整访问再观察；如果应用内出现的日历名称少于权限页列出的账户，说明应用侧的账户筛选或分组设置没打开，先处理这一层，不要跳到缓存。改动权限后建议退出应用重进一次再比对，避免权限状态没有重新读取。
核对被读取的日历账户与分组
确认权限范围没错之后，看系统日历这一侧。日历事件真正的来源是系统里的账户，应用只是读取方。需要拿到三条信息：账户列表、每个账户的同步开关、最近一次同步时间。
查看入口按平台不同，通常在这些位置：iOS 在“设置 → 日历 → 账户”，Android 在日历应用的账户管理或系统“账户与同步”里，macOS 在“系统设置 → 互联网账户”，Windows 在“邮件和日历”的账户设置。重点看被关闭的账户和长期没同步的账户。
Android 上可以用 adb 辅助确认账户和日历分组是否注册进来：
adb shell dumpsys calendar | grep -i -E "account|calendar"
# 需要结合设备版本确认输出结构，不同 ROM 字段名会有差异如果某个账户在系统列表里存在、但同步开关是关闭的，或者最近同步时间停在很早以前，应用读不到该账户的事件就是正常的。先把同步打开、手动触发一次同步，再回到应用比对。边界情况：只读订阅类日历（只订阅、不写入的日历源）本身不会同步你在本机的改动，跨设备复测时要把它排除。
排除本地缓存导致的旧数据显示
前两层都正常，但应用显示的仍是旧日程或漏事件，这时要判断是“数据没更新”还是“界面没刷新”。用三种操作做对比，每次操作后记录页面显示：
- 切换账户或日历分组：在应用内切到另一个日历再切回来，看事件是否重新出现或更新。
- 重启应用：完全退出（不是切后台）再打开，比对同一个时间段的事件列表。
- 手动刷新：下拉刷新或点击刷新按钮，记录刷新后的事件。
把三种操作前、后的显示写成对照，例如“重启前显示 3 条、重启后显示 5 条”。如果重启或手动刷新后就正确，问题多半在界面缓存而不是数据源，可以先用刷新作为临时手段，但要继续观察是否每次启动都复现。如果三种操作后依旧不对，说明本地缓存不是主因，继续下一层。这里要注意：清缓存或重启只是判断手段，不是解决同步延迟本身。
在跨设备改动场景下复测一次
如果旧数据只在“另一台设备改过事件”之后才出现，就要把应用本身的问题和设备间同步延迟分开。复测方法是一次只改一个变量：
- 在另一台设备（手机、平板或网页版）上新建或修改一条有明显特征的事件，记下修改动作发生的时间。
- 回到当前设备，不做任何清缓存或重启操作，观察该事件最早出现的时刻。
- 记录本机出现的路径：是直接出现在列表里，还是要手动刷新才出现。
判定依据是看这段延迟是否和其他日历客户端一致。如果在系统日历或其他日历应用里也出现同样的延迟，说明延误发生在账户同步链路，不在 Karpo 应用本身；如果只有 Karpo 延迟，而系统日历已经更新，再把范围收回到应用侧。做这一步时，建议把两端设备的时区和系统时间确认一次，时区设置不一致会让事件看起来“跑偏”或“漏掉”。
把核对结果整理成排查顺序表
把上面四层的结果按顺序记下来，下次再遇到“权限给了还是不准”可以直接照表走。每一层都有明确的判定标准和下一步指向：
- 授权范围：记录权限级别与已授权账户；判定标准是权限级别是否覆盖读取、应用内可见日历是否少于授权账户；不满足则先改权限或账户勾选，再重进应用。
- 账户与分组：记录系统账户列表、同步开关、最近同步时间；判定标准是目标账户是否开启且近期同步；不满足则先修系统账户同步，再回到应用。
- 本地缓存：用切换账户、重启应用、手动刷新三种操作对照显示；判定标准是三者中任一操作后是否恢复正确；恢复正确则以界面缓存为主，继续观察复现频率。
- 跨设备同步：在另一台设备改一条事件，记录本机出现时间；判定标准是延迟是否与其他日历客户端一致；一致则归因于同步链路，只有本应用延迟才回到应用侧继续排查。
可以照着这个模板记录，方便下次复用：
排查记录
[授权范围] 权限级别：____ 已授权账户：____ 应用内可见日历：____
[账户与分组] 目标账户：____ 同步开关：开/关 最近同步：____
[本地缓存] 切换账户前/后：____ 重启前/后：____ 手动刷新前/后：____
[跨设备] 另一台设备修改时间：____ 本机出现时间：____ 其他日历客户端是否同步：是/否
判定：____ 下一步：____四步的顺序不建议打乱：先确认能读到什么，再确认数据源是否在同步，然后判断显示层，最后才区分是不是设备间延迟。每一步只改一个变量并记录前后对比，能避免把权限、账户、缓存、同步几类问题混在一起。需要结合具体设备系统版本和客户端表现确认的字段，以本机页面和日志实际显示为准。