打卡类应用的数据模型与统计口径怎么设计？以念叙流年为例
做习惯打卡这类看起来"很简单"的应用，真正难的不是打卡按钮，而是底层的数据模型和统计口径。一个日期字段的边界处理不当，就会让用户看到"假完成"“假连续”，进而彻底失去信任。本文以「念叙流年」为例，聊聊打卡类应用在数据与统计设计上要注意什么。
一、先理解：打卡数据的核心矛盾
打卡应用表面是"记录某天做了某事"，实际要回答四个问题：
- 今天做了没有？（日粒度的幂等判断）
- 连续做了多少天？（连续统计）
- 累计做了多少天？（累计统计）
- 这些数据可信吗？（口径一致性）
前三个是功能，第四个是产品命门。用户一旦发现数据"对不上"（比如明明打了卡却显示没打），就会彻底放弃。所以统计口径设计往往比UI 更重要。
二、日志模型：以"天"为幂等单元 + 快照计价
1. 幂等设计：一天一条，按天去重。打卡记录不能简单地每次点击插一行，否则网络重试、用户连点，都会产生重复记录。正确做法是以"（习惯ID, 日期）"作为幂等单元——同一天重复提交不写第二笔。累计天数也应按"日期去重"统计，而非简单count 行数。
2. 统计日志窗口：不丢历史，可配置。打卡统计接口需要支持时间窗口参数：默认返回最近 365 天，最大可放宽到 3650 天。窗口下界要有兜底逻辑——不能越过"习惯开始日"，否则会把习惯还不存在的日子错标成"未打卡"。
3. 省钱累计：单价快照，隔离历史。对"花钱类"习惯（戒烟、戒酒）累计省下的钱时，不能用当前单价回算历史，否则用户改一次单价，历史账目全乱。正确做法是每天记录"当天单价快照"，历史金额固化。改价只影响之后的计算。
三、统计口径：连续 vs 累计，两个不同的判据
这是打卡应用最容易混淆的地方：
- 累计天数（streak 里的"累计"）：只要这天打了就算，按日期去重统计，只增不减，常用于 7 / 30 / 100 天里程碑判定——因为里程碑看的是"你坚持了多久"，不该因为断一天就归零。
- 当前连续天数（true streak）：从今天（或昨天）往回数连续打卡的天数，断一天就重新计算。
两者服务不同目的，必须分开实现，不能共用一个字段。搞混的结果就是"断了之后里程碑也跟着清零"，用户会认为之前的坚持白费了。
四、防"假完成"：跨天守卫与双判据
1. 跨天守卫（最容易踩的坑）。应用冷启动、断网重连时，本地缓存的可能是昨天的数据。如果直接渲染"完成状态"，用户会看到"昨天打的卡"被当成"今天已打卡"。所以判断"今天完成没"时，必须校验记录的日期是否等于今天，是则完成态，否则显示未完成。这就是跨天守卫。
2. 服务端与本地双判据。不信任单一来源：本地显示的状态只是即时反馈，最终与云端对齐。数据一致性由服务端兜底，本地与服务端各自判据明确，避免"假完成、假安心"。
五、关系模型：关爱者（双向关联 + 权限边界）
打卡应用常常还要支持"家人互相看进度"，这就需要一张双向关系表：
- 关系双建：长辈侧生成邀请码，家人接受后成为"关爱者"；关系记录双方。
- 权限边界：关爱者能看对方打卡进度，但查看"逐习惯明细"需要对方开启"明细可见"——默认不给，尊重隐私。
- 提醒克制：红点提醒只在"对方有习惯但今天一个都没打"时亮，打了哪怕一个就不打扰。远程关爱最忌变成骚扰。
- 邀请码设计：长码可无状态生成（可转发多人），短码（6 位数字）落库仅登录后接受，公开接口不认——避免短码被探测。
六、给打卡类应用的几条设计建议
综合上面，做打卡类应用，技术上值得记的：
- 统计口径优先于功能——宁可功能少，也要保证"完成/连续/累计"绝对可靠，这是信任基础。
- 区分"累计"和"连续"——里程碑用累计（不归零），当前连通用真实连续，分开实现。
- 幂等从底层做起——(习惯, 日期) 唯一约束，避免脏数据。
- 历史不可变——改单价、改设置都不能污染已记录的数据，用快照隔离。
- 跨天要守卫——任何"今天完成没"的判断都要校验日期，防缓存导致的假完成。
- 远程功能要克制——默认最小权限，提醒宁可少亮不轰炸。
如果你也在做打卡/习惯养成类应用，欢迎交流——这块的细节坑，比界面多得多。
