相册小程序开发

项目背景

这是一个成长记录类小程序，2 个仓库。接口端用 Go 写，带 Docker 部署配置；应用端用 TypeScript 加 Vue。最后提交在 2025 年 9 月。要做的事情不复杂：按时间轴记录影像，照片与印迹都能进同一条记录，家庭成员共享同一个记录空间。

客户当时的状态

看起来很简单的功能，落到实现上有两个实际约束。一是图片：家庭记录里照片是主力内容，原图体积大，直接存原图，存储和加载都吃不消；压得太狠，画质又没法看。二是时间轴：记录是按时间累积的，越到后面数据越多，一次性把几年的记录渲染出来，页面会卡。这两件事不定策略，功能做得再全也用不住。还有一点是时限：记录类产品的数据只增不减，任何一次「先跑起来再说」的技术选择，两三年后都要连本带利还回来。

我们的做法与取舍

第一个取舍是图片做压缩与多规格存储，而不是只存原图。展示用压缩后的规格，需要看细节时再取原图。代价是存多份、多一步处理，收益是加载速度可控。

第二个取舍是时间轴按需加载，不做一次性全量渲染。时间轴这类界面必须假设数据会一直长下去，按段加载是唯一能长期用的做法。

第三个取舍是把「共享同一个记录空间」做成核心模型，而不是给每个人各建一份再想办法合并。多成员共享是这类产品的本质，模型一开始就要按这个来。

系统怎么承载这条链路

接口端负责用户与家庭空间、记录与影像的存储，以及图片处理；应用端负责时间轴展示与录入。两端之间是常规的前后端分离结构，接口端带 Docker 配置，部署不依赖人工逐台配环境。图片处理与记录存储都在接口端统一完成，应用端不承担计算，这样不同终端的展示效果也能保持一致。

交付状态与边界

代码处于维护状态，最近一次提交在 2025 年 9 月。边界说明：存储与流量成本随记录量增长，影像类产品这是必须提前算的账，我们只能通过压缩策略把它控制在合理范围；我们做的是记录与管理，不做影像的编辑与美化；家庭空间的数据可见范围取决于贵方的隐私约定，系统提供能力，规则由业务方制定。