开发日志 002：围绕真实遗漏设计补打卡、周期与设置

日常打卡不能只处理理想的一天

最初的一键打卡解决了“今天记一下”的核心动作，但真实使用并不总是按设计发生：有人当天完成了却忘记点按钮，有人配了新药需要重新计算进度，也有人只想调整提醒时间，不希望在设置里面对一长串无关选项。

这一阶段没有增加复杂的健康档案，而是围绕三个高频问题扩展功能：遗漏如何补记、药物周期如何按实际情况计算、提醒和周期配置怎样放进一个容易理解的设置入口。设计原则始终不变——操作要少，状态要清楚，修改后要立刻看得见结果。

补打卡：允许修正，但不把历史记录变成任意编辑

补打卡入口被放在月历中。过去未打卡的日期以普通灰色显示，点击后弹出带日期的确认框；确认才会写入该日期记录，并立即刷新日历和统计卡片。已打卡、未来日期和今天的状态不会走这条路径，避免用户误触或把未来计划提前写成完成记录。

这种设计保留了对真实遗漏的容错：用户不需要为了补一天记录去填写表单，也不用离开当前日历页。但它仍然把“补记”明确为一次需要确认的操作，而不是让所有日期都能被随意改写。日历承担的也不只是展示任务，它成为历史状态和修正入口的同一张地图。

补记成功后，页面会同步更新周期进度、累计天数与当前月展示。数据只有一份，界面只做重新计算和渲染，避免出现“日历已经点亮，统计却还是旧数字”的双状态问题。

周期打卡：按实际完成次数，而不是日历翻页

固定 21 天的自然日倒计时看起来简单，但一旦漏记，就无法反映真实的使用进度。项目将周期定义为从周期开始日之后累计完成的打卡次数：默认 21 天，用户可以在 1 到 90 天之间调整。没有打卡的日期不会消耗周期，因此预计用完日期会随实际完成节奏顺延。

首页统计卡片保留“本周期打卡”和“累计打卡”两项：前者显示当前进度与预计用完日期，后者提供长期记录和首次打卡时间。点击周期统计列还能打开周期详情，查看开始日期、目标天数和当前累计情况。这种分层避免把全部计算过程堆在首页，同时让最需要回答的问题——“还差多少”“大概什么时候需要补药”——随时可见。

新配药是另一个明确的业务节点。设置页提供“从今天开始新周期”入口，将周期开始日暂存为当天，用户确认保存后才写入本地。旧打卡记录不会被删除，只是后续的周期计算从新的锚点重新开始。

设置页：把相关选择放在一起

设置界面采用独立布局，将内容分为“每日提醒”和“配药周期”两组。前一组包含提醒开关和时间选择；后一组包含周期开始日期、周期天数以及新周期入口。每一行使用左侧标签、右侧当前值的形式，分组标题和分隔线帮助用户快速区分“什么时候提醒我”和“怎样计算我的进度”。

交互上，时间使用系统时间选择器，周期开始日使用日期选择器，周期天数使用限制在 1 至 90 的数字选择器。用户在对话框中修改的值先保存在临时变量中，只有点击“保存”后才调用提醒调度、写入周期设置并刷新主页面；点击取消则不改变原来的有效配置。这个小的事务边界让设置过程可预期，也避免用户随手点进一个选项就意外改动提醒。

提醒开关关闭时会取消已调度闹钟；开启后则以新的时间重新调度。周期日期和天数的保存同样立即触发界面重算，保证设置、存储和展示是同一轮更新。

阶段结果

补打卡、周期打卡和设置界面让应用从“每天点一次”的单点功能，扩展为能够处理遗漏、重新配药和个人节奏调整的日常工具。它仍然不试图替用户做医疗决策，而是把记录、提醒和进度计算做得足够直接、足够容易恢复。

后续若增加多组药物或数据导出，会继续沿用这一思路：先保证每个状态的来源明确、修改路径可逆，再讨论更复杂的功能层级。