鸿蒙端云一体实战：用 FunctionGraph 云函数实现一个云同步待办清单

前言

昨天聊了 ArkTS 声明式 UI 的端侧渲染思路，今天换个视角：当一个纯端侧应用需要「多端同步」时，云端该怎么配合。正好在鸿蒙开发实践中心走了一遍「云同步待办清单」案例，本文把它的端云一体架构拆开讲清楚，并给出可直接参考的云函数实现。

为什么需要端云一体

纯端侧应用（昨天的数独游戏就是）状态存本地文件即可，因为数据只属于一台设备。但待办清单这类生产力工具，用户的真实诉求是：

• 手机上创建的任务，平板上立刻能看到
• 换新设备登录即恢复，不丢数据
• 多端并发修改不能互相覆盖

这就要求把「任务、会话」等核心状态收口到云端，端侧只做展示与交互。案例给出的方案是华为云 Serverless 全家桶：FunctionGraph 承载业务逻辑，APIG 暴露统一接口，RDS MySQL 持久化三张表（users / sessions / tasks）。

8 个云函数的职责切分

案例把后端拆成 8 个 FunctionGraph 云函数，每个只做一件事：

1. register / login：注册登录，签发会话
2. createTask / updateTask / deleteTask：任务增删改
3. listTasks：按用户拉取任务列表
4. sync：增量同步，返回上次同步后的变更
5. verify：验收接口，部署后自检

这种「一函数一职责」的拆法好处很明显：函数粒度小，冷启动快，出错时排查范围天然收敛。注册、鉴权、任务 CRUD、同步各自独立，改同步逻辑不会碰登录。

增量同步的关键设计

多端同步最容易犯的错误是「每次打开 App 全量拉一遍」。任务量小没事，任务一多流量和延迟都会恶化。案例的 sync 函数采用增量方案：

• 每个任务记录带 version 与 updated_at
• 客户端本地记一个 last_sync_time
• sync 只返回 last_sync_time 之后变更过的记录

端侧配合一个 30 秒一次的轮询，多端数据最终收敛一致。为什么不直接上 WebSocket？Serverless 架构下长连接成本高，轮询加增量的组合在中小规模场景反而更经济，这是很务实的取舍。

云函数代码示例

以 updateTask 为例，核心逻辑就是「鉴权 → 校验 → 落库」，保持函数纯粹：

exports.handler = async (event) => {
  const { taskId, title, priority, done } = JSON.parse(event.body);
  const session = await verifySession(event.headers.authorization);
  if (!session) return { statusCode: 401 };

  const result = await db.query(
    'UPDATE tasks SET title = ?, priority = ?, done = ?, version = version + 1 WHERE id = ? AND user_id = ?',
    [title, priority, done, taskId, session.userId]
  );
  if (result.affectedRows === 0) return { statusCode: 404 };
  return { statusCode: 200, body: JSON.stringify({ ok: true }) };
};

两点值得注意：

• SQL 条件带 user_id：权限校验下沉到数据层，越权操作直接 404，比在业务层判断更可靠
• version 自增：为增量同步提供单调序号，避免用时间戳排序时同秒写入的乱序问题

部署与验收

案例给了两个脚本：deploy.sh 一键部署全部函数与网关配置，verify_api.sh 端到端验收。这套「部署脚本加自动验收」的组合值得直接抄进自己的项目——验收脚本跑通意味着注册、登录、建任务、改任务、删任务、同步全链路都活着，而不是「部署完成但接口 500」。

小结

端云一体的核心不是把逻辑全搬上云，而是想清楚「哪些状态属于云、哪些留在端」。FunctionGraph 这种 Serverless 形态把运维成本压到最低，配合 APIG 和 RDS，个人开发者也能撑起一套可靠的多端同步服务。跑完这个案例最大的收获是：8 个小函数胜过一个大单体，增量同步胜过全量轮询。感兴趣的同学可以去鸿蒙开发实践中心把案例跑起来，60 分钟就能部署跑通。