成长记录通常停在微信、云盘和各自手机里。想补一句留言找不到原图，想给爷爷奶奶看又不敢把相册设成公开。权限、日期和「这是谁写的」没有被当成产品对象，只被当成存储附件。
记录发生在碎片时间、常常是一只手抱着孩子。如果流程超过两步，这件事会重新退回群聊。
Case 04 · 宝宝成长相册
成长不该散落在群聊里。
家人要的是共同写下、共同看见、并且只给家里人看见。相册把照片收成私密时间轴，而不是又一个会外流的朋友圈。
The Problem
照片很多，家却没有一本。
痛点
- 原图外链可被任意打开
- 家庭角色权限含糊
- 年月与月龄对不上
- 上传中断后草稿丢失
The Solution
两步记下，按角色看见。
两步记录
选择日期、上传照片，留言可选。EXIF 可建议日期。多图排序与删除在同一条记录里完成。
一个家庭，一个宝宝
OWNER 维护资料与邀请，MEMBER 共同记录。移除成员后历史保留，访问立即失效。
私有对象存储
原文件进私有 Bucket，前端只使用短时访问地址。
两种时间
时间倒序浏览，可在年月与月龄之间切换。
限时邀请
链接或邀请码加入，不把家庭变成开放社区。
The Process
从家庭对象到可同步的服务。
-
建家
账号之后先问家庭
登录成功：已有家庭进时间轴；没有家庭则只能创建或凭邀请加入。避免游客误入示例家庭。
-
记下
草稿跟着人走
上传未完成时本地暂存，并提醒网络恢复。抱着孩子的那只手不应该因为刷新而重来。
-
同看
权限先于滤镜
会话 Cookie、密码哈希、家庭成员表和私有存储一起构成「只有家里人能看」。灯箱与轮播建立在这条约束之上。
-
上线
数据库与照片分开备份
PostgreSQL 保存记录与关系，OSS 保存原图。部署后按日备份数据库；照片需要独立的版本或备份策略。
The Trade-offs
记忆可信，比相册好看更重要。
做进 MVP
- 登录、一个家庭、一个宝宝
- 记录、留言、邀请、成员移除
- 移动底栏 / 桌面侧栏
- 类型检查、单测与 E2E
明确不做
- 社区、点赞、公开广场
- 滤镜、视频、实体纪念册
- 一个家庭多个宝宝
- 自动文案美化——成长记录的可信来自家人原话和原图
若以后加入 AI，也只能是可选的整理，而不能绕过权限，更不能改写家里人写下的句子。
The Results
家庭协作被当成真实功能验收。
2
步完成一条记录
2
角色：OWNER / MEMBER
OSS
私有存储 + 短时地址
HTTPS
已部署家庭同步入口
当前版本接入真实账号、家庭权限、PostgreSQL 与阿里云 OSS。完整上传仍依赖对象存储配置；没有 RAM 角色时可以浏览，但不能把示例家庭当成已验证的权限隔离。数据库备份保留 14 天，与照片备份相互独立。