打开 App 卡在加载超过三秒，用户往往就直接关掉了。

记录类工具最怕两件事：一是慢（打开半天刷不出来），二是丢（换手机或重装，记录全没了）。我做「简单记」时，在这上面花了最多心思。

这套数据层，是我用 WorkBuddy 加腾讯混元（hy3）一点点调出来的。我本来不是程序员，在能源行业干了二十多年，写代码是半路出家。下面这套"本地为主、云端兜底"的取舍，你照着做，也能做出自己的小工具。

说白了就是一件事：怎么既保住本地的快、离线可用，又拿到云端的跨设备、不丢失。

一、矛盾：本地快但不跨设备，云上全但不实时

数据存本地，打开秒开、没网也能记。但换手机，记录全没了。

存云端，哪儿都能看。可一断网就用不了，每次读取还得等网络往返。

成年人说"我都要"，还真能办到。

可直接复制的提示词： 我的小工具要存数据，帮我对比"只存手机本地"和"只存云端"的优缺点，再给我一个"本地+云端"的折中方案。

二、我的取舍：本地为主，云端兜底

核心在 utils/cloudStore.js。

读取时优先走本地缓存：数据已在手机上，打开即显示、断网也能看。写入时先落到本地存储（同样秒开、离线可用），再由程序在后台悄悄把这份数据镜像到云端，本地写成功就立刻返回，不卡界面、不等网络。

真实的写入逻辑如下（已做精简，仅保留主干）：

1
2
3
4
5
6

// 写入：先落本地，再异步镜像云端
function set(key, value) {
  wx.setStorageSync(key, value)              // ① 本地先写，秒开、离线可用
  if (!_openid) return
  callSync('push', { payload: buildPushPayload() })  // ② 再异步推云端，失败进重试队列
}

好处很直白：没网也能记；云端哪怕挂了，本地照常跑。

先保证"能用"，再追求"同步"，这个顺序不能反。

可直接复制的提示词： 我要"本地优先、云端兜底"地存数据，给我一段最小可运行的写入逻辑，并说明哪一步保证离线可用。

三、跨设备同步：先认人是关键

登录时，app.js 的 login() 用 wx.login 拿到 openid，绑到全局。

云端数据按 openid 分桶——你的记录不会混进我的。

每次切回前台，做一次增量 pull：只拉差异，不整库重刷。快，还省流量。

可直接复制的提示词： 我的工具要支持多设备，帮我说清楚：怎么识别"这是谁的数据"、怎么只同步变化的部分，而不是每次全量重传。

同步这事儿，第一步不是传数据，是认出这是谁的数据。

四、一个工程细节：记录为什么要拆表

record_entries 我拆成了独立集合，每条一文档：

1
2

// docId = openid::entryId，存 _openid + date，便于按日期高效扫描
docId = openid::entryId

为什么特意把记录拆成独立集合？因为后面要做"每日定时提醒"，需要按日期高效地一条条扫描。如果这些记录全都混在一个大对象里，定时任务每次都得翻整个库，扫得很慢；拆成独立集合、再给日期建索引，扫描就快了。

配套加了 reminder_log 做去重。

今天的结构，就是给明天的功能留余地。

五、部署前提（坑先说清）

云开发控制台得建几个集合：user_data / users / subscriptions / record_entries / reminder_log。

云函数 getOpenid、syncData 要"云端安装依赖"部署；sendSubscribe 还得在 CloudBase 控制台把小程序和微信公众平台关联、开通订阅消息权限。

搭建服务端（建集合、部署云函数、关联权限）是用户完全看不见的准备工作，却替你挡掉了后面大量的联调和报错。这一步没做踏实，前面写得再漂亮，一运行就报错跑不起来。

六、收藏这张「数据架构自查清单」

截图存下来，设计任何数据存储前扫一遍：

收尾

数据架构没有标准答案，说到底就是"本地为主、云端兜底"这层取舍。

下篇：数据齐了，怎么让小程序替我"看"出规律？讲接大模型做智能解读。