鸿蒙待办清单案例实操：30秒轮询改推送，我拿AI DevSpace算了一笔账

今天上午（11月13日）我照着成长中心的每日任务，把鸿蒙实践中心的案例《云同步待办清单：鸿蒙端云一体实战》从头读了一遍。这个案例是 ArkTS + Serverless 的端云一体待办清单：端侧 ArkTS，云端 8 个 FunctionGraph 云函数，中间过 APIG，数据落在一张 RDS MySQL 里，三张表 users、sessions、tasks，仓库还给了 deploy.sh、verify_api.sh、verify_comprehensive.sh，案例自己标的预计耗时是 150 分钟，更新时间 2026-10-20。

案例写得挺实在，有几处细节我划了线。登录凭证不走 JWT，塞在 HTTP Header 里的 X-Auth-Token 是一段 SHA256 哈希；APIG 发过来的 body 是 base64，得先 decode 再 JSON.parse；时间不直接拿服务器的，单开了一个 dateStrings 枚举加 getBeijingTime 统一转北京时间；端侧列表渲染 ForEach 必须拿 id 当 key，用 index 当 key 会删错行；第一次调云函数经常 504，因为冷启动，端侧写了 3 次重试兜底；多端同步最糙也最直接，每 30 秒轮询一次 GET /todo/pull。密码用 scrypt 加密，参数写死了 N=4096。案例也直接说了，演示账号 demo@example.com / 123456 能用，注册没做邮箱验证，所谓“逾期”就是前端拿 todos.find(todo => todo.isOverdue) 现算的，都是演示级别，别直接抄去生产。

读完我就带了两个问题进 AI DevSpace。进的是体验版，进门没有再要短信码，也没有让我勾 AK/SK 同步，今天没弹这个。体验版有 3 小时倒计时，到点自动释放。上午 10 点 13 分，我在 AI Shell 里新开了一个会话，工作目录默认 /root/workspace，把问题原样丢了进去：30 秒轮询能不能改成服务端主动推，到底要动哪些地方；还有冷启动那个 3 次重试，生产上够不够。

先说一下 AI 当时的真实表现。它先去联网查，搜索直接撞上了 HTTP 429 的速率上限；接着它自己拼了两个仓库链接去抓，全是 404；还想打开浏览器验证，也没成功。这几下没成，它就拿我给它的架构细节接着往下写。这一点我得说清楚，它的回答是建立在我喂给它的信息上的，不是它自己读了仓库。回答在 10 点 16 分写完，会话标题直接就叫“鸿蒙待办清单：轮询改推送与冷启动重试策略”。

轮询改推送，它给了三条路，我觉得账算得清楚。FunctionGraph 本身推不了消息，Serverless 函数有请求才跑，没常驻进程握不住长连接，所以要另加一条推送通道。最顺的是 HMS Push Kit 加下拉：往 sessions 表加一个 push_token 字段，多写一个云函数 register_push_token 用来上报，写任务的函数在写完 RDS 之后去调 Push 接口，端侧收到推送再去调一次 /todo/pull，顺手把原来那个 30 秒定时器删掉。延迟从最坏 30 秒变成秒级，省电，云端还是纯 Serverless。代价也写明白了：推送不保证 100% 到达，最好留一个 5 分钟的兜底轮询；每次写任务要多花 100 到 300 毫秒调推送。另一条路是 APIG 接 WebSocket，这就得在后面挂一台常驻的 ECS 或 CCE，Serverless 白搭了，给一个待办清单属实没必要。还有长轮询，按 FunctionGraph 按时长乘内存计费的算法，一次 25 秒占用和原来 200 毫秒的调用比，成本大概翻 125 倍，不划算。它推荐走第一条，我认这个结论。

再说重试那 3 次。AI 提醒的点我之前没想细：504 不一定是冷启动，也可能是 APIG 超时；要是 3 次重试加起来还没冷启动耗时长，重试在函数热起来之前就死完了。而且 8 个函数冷启动是各自独立的，轮询一直在刷 /todo/pull，这个入口不容易冷，但写任务那几个函数平时没请求，正好是最容易冷的。更麻烦的一处是，写操作重试遇到 504，第一次请求其实可能已经写进数据库了，再重试就容易重复落库。还有两个毛病：重试间隔固定，没有抖动，并发一上来容易扎堆撞在一起；它也没有区分错误类型，正确的做法是只对 502、503、504 这类重试，500 就别重试了。生产上要补的几件事它也列了：把 APIG 超时抬到 30 秒、给高频函数配预留实例、后台定时预热、所有写操作带幂等键（请求带 UUID，RDS 加唯一约束）。

这两段问答连起来还有一个交叉点，今天我觉得最值回时间：轮询一直在刷，其实顺手把函数刷热了。哪天真把轮询拆了，冷启动反而更频繁。所以顺序应该是先配预留实例，再上推送，别两件事一起动。

今天在 GitCode 上我还顺手 Star 了这个案例的仓库 harmony-practice-center/todo_list，点之前是 480 个 Star，点完变 481。登录走的是手机验证码，获取验证码那一步没有弹拼图验证，挺顺。

11 月 30 日零点博客业务就要下线（昨天 15:08 发的公告），这篇文章赶在下线前发出来，也算是给这几天在成长中心刷任务留个记录。接下来我打算拿演示账号真跑一遍这个待办清单，重点验证一下冷启动那一下 504 和 3 次重试到底什么表现，跑完再更新。