从鸿蒙云相册案例看端云分工：照片存 OBS，数据存数据库，体验先存本地

今天在鸿蒙开发实践中心浏览了“用 OBS 打造个人云相册”案例，又在 AI 开发者空间里用 AI Shell 问答验证了思路。把学习到的端云分工整理成三点体会，写给同样想做端云同步类小应用的开发者参考。

一、媒体文件和结构化数据要分开存

云相册里有两类东西，存法完全不同：

• 照片、视频这些大文件，适合放对象存储 OBS：容量几乎没有上限，按实际用量计费，换手机也不怕丢；
• 相册名、照片的拍摄时间、标签、收藏状态这些结构化数据，适合放数据库：方便按时间、标签检索，也方便做同步时的增量比对。

端侧只保留一份索引和缩略图缓存，需要看原图时再按需从云端取。这样做的好处是：本地不占满存储，云端按量花钱，备份和分享也都有了着落。反过来如果把照片原图全塞数据库，表会迅速膨胀，查询和备份都会变慢。

二、体验上坚持“本地优先”

新建一张照片时，最好的体验是：点保存，列表里立刻出现，根本不用等网络。做法是先写端侧数据库并刷新界面，再把变更异步同步到云端。离线、弱网时应用照常用，联网后按时间戳或版本号合并，有冲突以最新一次操作为准。

这条原则同样适用于待办、日记、笔记类应用：先保证单机可用，再补云端同步。同步是加分项，不是可用性的前提。

三、鉴权与密钥不要图省事

这类应用至少要守住三条底线：

1. 登录后服务端发令牌，端侧用安全存储保存令牌，不要长期保存账号密码；
2. 数据库密码、对象存储密钥只放在服务端配置文件里，绝不写进端侧代码，更不要提交到公开代码仓；
3. 端侧上传下载走服务端签发的临时凭证或预签名链接，长期密钥不出服务端。

我在 AI 开发者空间体验时也特意只问了一个知识性问题，没有在对话里贴任何密钥——开发习惯要从第一天养成。

四、落地顺序建议

先把最小闭环跑通，再加分类、搜索、分享这些功能；每一步都有可观察的结果，出了问题也容易定位。

小结

云相册这类应用的核心不是堆功能，而是把分工想清楚：大文件交给对象存储，结构化数据交给数据库，体验交给本地优先，安全交给服务端鉴权。分工对了，后面加功能才不会越改越乱。