夜雨聆风记录类工具最怕两件事：一是慢（打开半天刷不出来），二是丢（换手机或重装，记录全没了）。我做「简单记」时，在这上面花了最多心思。
这套数据层，是我用 WorkBuddy 加腾讯混元（hy3）一点点调出来的。我本来不是程序员，在能源行业干了二十多年，写代码是半路出家。下面这套"本地为主、云端兜底"的取舍，你照着做，也能做出自己的小工具。
说白了就是一件事：怎么既保住本地的快、离线可用，又拿到云端的跨设备、不丢失。
一、矛盾：本地快但不跨设备，云上全但不实时
数据存本地，打开秒开、没网也能记。但换手机，记录全没了。
存云端，哪儿都能看。可一断网就用不了，每次读取还得等网络往返。
成年人说"我都要"，还真能办到。
可直接复制的提示词：
我的小工具要存数据，帮我对比"只存手机本地"和"只存云端"的优缺点，再给我一个"本地+云端"的折中方案。
二、我的取舍：本地为主，云端兜底
核心在 `utils/cloudStore.js`。
读取时优先走本地缓存：数据已在手机上，打开即显示、断网也能看。写入时先落到本地存储（同样秒开、离线可用），再由程序在后台悄悄把这份数据镜像到云端，本地写成功就立刻返回，不卡界面、不等网络。
真实的写入逻辑如下（已做精简，仅保留主干）：
// 写入：先落本地，再异步镜像云端functionset(key, value) {wx.setStorageSync(key, value) // ① 本地先写，秒开、离线可用if(!_openid) returncallSync('push', { payload: buildPushPayload() }) // ② 再异步推云端，失败进重试队列}
好处很直白：没网也能记；云端哪怕挂了，本地照常跑。
先保证"能用"，再追求"同步"，这个顺序不能反。
可直接复制的提示词：
我要"本地优先、云端兜底"地存数据，给我一段最小可运行的写入逻辑，并说明哪一步保证离线可用。
三、跨设备同步：先认人是关键
登录时，`app.js` 的 `login()` 用 `wx.login` 拿到 `openid`，绑到全局。
云端数据按 `openid` 分桶——你的记录不会混进我的。
每次切回前台，做一次增量 pull：只拉差异，不整库重刷。快，还省流量。
可直接复制的提示词：
我的工具要支持多设备，帮我说清楚：怎么识别"这是谁的数据"、怎么只同步变化的部分，而不是每次全量重传。
同步这事儿，第一步不是传数据，是认出这是谁的数据。
四、一个工程细节：记录为什么要拆表
`record_entries` 我拆成了独立集合，每条一文档：
// docId = openid::entryId，存 _openid + date，便于按日期高效扫描docId = openid::entryId
为什么特意把记录拆成独立集合？因为后面要做"每日定时提醒"，需要按日期高效地一条条扫描。如果这些记录全都混在一个大对象里，定时任务每次都得翻整个库，扫得很慢；拆成独立集合、再给日期建索引，扫描就快了。
配套加了 `reminder_log` 做去重。
今天的结构，就是给明天的功能留余地。
五、部署前提（坑先说清）
云开发控制台得建几个集合：`user_data / users / subscriptions / record_entries / reminder_log`。
云函数 `getOpenid`、`syncData` 要"云端安装依赖"部署；`sendSubscribe` 还得在 CloudBase 控制台把小程序和微信公众平台关联、开通订阅消息权限。
搭建服务端（建集合、部署云函数、关联权限）是用户完全看不见的准备工作，却替你挡掉了后面大量的联调和报错。这一步没做踏实，前面写得再漂亮，一运行就报错跑不起来。
六、收藏这张「数据架构自查清单」
截图存下来，设计任何数据存储前扫一遍：
| 每一次，我都亲自验收了吗？（最重要的一条） |
收尾
数据架构没有标准答案，说到底就是"本地为主、云端兜底"这层取舍。
下篇：数据齐了，怎么让小程序替我"看"出规律？讲接大模型做智能解读。
你的 App 假如断网，还能正常记吗？评论区说说 👇
关注「随遇而学」，领一份我自己整理的 AI 减负模板包：含需求描述模板、与 AI 沟通的话术清单、常用小工具清单，以及可直接打开使用的 Excel / Word / PPT 文件模板。
领取方式：在公众号对话框回复关键词「模板」即可获取。也可点底部菜单「模板下载」浏览。
我是知行，在办公室一线干了二十年，现在主要分享用 AI 把重复工作压到三分钟的实测方法。下一篇见。
