多多小叙事：我为女儿重新做了一个成长记录小程序

2024 年 4 月，我发布了“多多小叙事”的第一个版本。

那一版是我自己一点点手写出来的。它让我第一次把“给女儿做一个成长记录工具”这件事变成了可以运行的小程序，但功能并不完整，记录、浏览、图片和权限之间也没有真正形成闭环。它能打开，却没有成为一个可以长期使用的家庭工具，后来基本没有真正用起来。

两年后，我重新做了第二版。

这次我不再把目标定为“做出一个小程序”，而是做一个自己和家人真的愿意长期使用的记录工具：录入要足够简单，照片要可靠保存，过去的内容要方便回看，家人可以看，但不同内容也要有清楚的权限边界。

为什么叫“多多小叙事”

多多是我的女儿。

这个项目只为她一个人存在，不打算做成通用育儿平台，也不需要社交、打卡、排行榜或者复杂的数据看板。名字里的“小叙事”，表达的是那些看起来很小、以后却可能很珍贵的事情：第一次学会什么、一次普通的出行、一顿喜欢的饭、一张某个月的照片，或者某天重新量下的身高和体重。

我希望留下的不是一份面面俱到的成长档案，而是一条能慢慢积累、以后还愿意翻看的小路。

小程序入口

微信扫描下面的二维码，可以打开“多多小叙事”小程序。

第二版解决了什么

第二版把记录拆成三个彼此独立的维度。

小叙事

“小叙事”用来记录日常生活、成长变化和值得回看的片段。它没有标题，正文和图片至少填写一项，并通过分类和标签组织内容。

列表采用时间轴形式，可以按正文、年份、月份、分类和标签查找。每条记录支持 0 到 9 张图片，第一张图自然成为列表代表图，不需要再单独维护封面。

每月一照

“每月一照”用于观察多多每个月模样的变化。每个自然月最多一条记录，可以放 1 到 9 张照片，再写一段可选的当月小记。

它与小叙事相互独立，不会因为上传了一组月度照片，就自动生成另一条日常记录。少一个看似聪明的自动关联，反而让每种记录的意义更清楚。

长成记

“长成记”记录测量日期、身高、体重、地点和备注。年龄由出生日期和测量日期自动计算，不需要手工填写。

这一版只做可靠的测量记录和时间轴浏览，没有急着加入趋势分析或健康评价。先把原始记录长期、准确地留住，比生成更多图表更重要。

首页和日常使用

首页保持得很简单：多多的照片 Banner、名字、出生日期、当前年龄、家庭寄语，以及三个记录入口。

Banner 支持多张图片左右滑动。管理员可以直接在小程序里上传、排序、删除和保存 Banner，保存后回到首页会刷新一次；平时切换页面不会反复请求首页数据。

小程序底部只有“首页”“小叙事”“我的”三个入口。使用最频繁的小叙事可以直接进入，每月一照和长成记从首页进入。“我的”用于查看当前身份、申请成为家人、切换浏览模式，以及进入少量管理员功能。

家庭项目也需要权限

这是一个私人家庭项目，但“只给家人用”不等于不需要权限设计。

系统区分管理员、家人、亲友和访客四类角色。爸爸是管理员；家人角色目前用于多多和妈妈，也就是早期设计里所称的“核心成员”；其他获准加入的家庭亲友使用亲友角色。角色决定能做什么，“与多多的关系”只负责说明具体身份，两者没有混在一起。

内容有三个可见范围：

• 核心成员可见
• 家人可见
• 公开

这里的“公开”是允许进入小程序的访客查看，并不是把家庭照片发布到公开互联网。

管理员可以管理全部内容；家人可以新增记录，但只能修改和删除自己创建的内容；亲友和访客以浏览为主。页面会隐藏无权使用的按钮，后端仍会再次校验，不能把安全只寄托在前端显隐上。

新用户通过微信完成身份识别后先以访客进入，不强迫立即提交申请。需要查看更多家庭内容时，可以从“我的”提交亲友申请。管理员能够在小程序中审核申请、确认关系并分配角色。

图片链路是这次重做的重点

第一版不实用，一个重要原因就是图片能力没有真正形成稳定闭环。成长记录离不开照片，所以第二版把附件作为独立能力认真处理。

小程序选择图片后，先向业务后端申请本次上传所需的短期信息，再直接上传到附件服务。业务记录保存时只提交附件关系，不关心文件在服务器上的物理路径。

图片链路区分两种用途：

• 首页、列表和时间轴使用缩略图，减少流量和加载时间。
• 详情和图片预览使用原图，保留查看质量。

附件服务负责原图、压缩图、缩略图、访问和清理；业务后端负责记录权限以及附件和业务数据之间的关系。超大图片在小程序端进行一次尺寸预处理，上传失败可以重试，已有图片也能够重新排序或删除。

这种拆分比把所有图片处理都塞进业务代码复杂一些，但边界更清楚，也更适合长期维护。

当前技术架构

第二版没有使用跨端框架，小程序端采用原生微信小程序加 TypeScript。后端使用 Java、Spring Boot 和 Sa-Token，业务数据存储在 MySQL，图片交给独立的附件服务。

整体调用关系可以简化为：

微信小程序（原生 + TypeScript）
          |
          | HTTPS / JSON
          v
Spring Boot 业务应用
├─ blog 模块
└─ duoduo 模块
    ├─ 微信登录与业务会话
    ├─ 角色、权限和可见范围
    ├─ 三类成长记录
    └─ 附件关系与上传编排
          |
          ├────────> MySQL
          |
          └────────> 独立附件服务
                     ├─ 原图
                     ├─ 压缩图
                     └─ 缩略图

后端工程采用 Maven 多模块结构，application 是统一启动入口，原有博客业务在 blog 模块，多多小叙事在 duoduo 模块。两个业务模块保持边界，但运行在同一个 JVM 中，避免在资源有限的服务器上再增加一套常驻 Java 进程。

生产环境通过 HTTPS 对外提供服务，域名、数据库、微信密钥和附件配置都放在外部配置中，不写死在代码里。服务器资源并不宽裕，因此 MySQL、搜索服务、业务 JVM 和附件服务都按照轻量化原则配置。

这次没有再为小程序单独开发一套新的后台管理系统。当前需要频繁操作的 Banner 和亲友审核已经放进小程序；其他基础资料仍可以通过数据库或既有管理能力维护。等实际管理需求积累到足够明确时，再决定是否建设新的家庭自用后台。

不只是把页面写出来

这次重做按照需求、产品结构、原型、技术架构、数据库与接口、开发准备、后端、小程序、联调发布九个阶段推进。

这套过程看起来比直接写代码慢，但它解决了第一版最根本的问题：功能不是零散地“能运行”，而是从记录、上传、权限、浏览到发布形成完整闭环。

例如，一张图片从选择开始，会经过尺寸处理、上传授权、附件直传、业务关系保存、缩略图展示和原图预览；一条记录也会同时受到角色、创建者和可见范围约束。只有这些路径都连起来，产品才真的可用。

第二版最终完成了正式环境部署、微信登录、真机测试、图片链路和主要业务流程验证，并已经正式发布。

第一版留下了什么

2024 年的第一版虽然基本没有用起来，但它并不是一次没有意义的尝试。

它验证了我确实想为多多做这件事，也让我看见“做出来”和“能长期用”之间的距离。第二版没有继续在旧代码上打补丁，而是把旧版当作参考，重新确认到底要记录什么、谁可以看、怎样才能更容易坚持。

如果说第一版是把想法写成程序，第二版才是把它做成一个家庭工具。

接下来

项目现在会先进入稳定使用阶段。评论、点赞、留言、视频、身高体重趋势、成长统计、订阅消息和家庭自用管理后台都只是后续候选，不会因为“技术上能做”就马上加入。

我更希望先真正使用它，持续记录，看看哪些需求会在日常生活里反复出现。下一轮开发仍然会围绕同一个原则：只解决这个家庭真实需要的问题，不把“多多小叙事”做成另一个复杂的平台。

第一版让我开始，第二版终于让我可以认真地记录下去。