8 个 FunctionGraph 云函数撑起一个待办应用：拆分边界与踩坑记录

端云一体待办清单的后端用了 8 个 FunctionGraph 云函数，配合 APIG 专享版和 RDS MySQL 三张表。拆完之后回看，有几个决定值得记下来。

粒度上我按「一个业务动作一个函数」拆：注册登录、列表查询、新增、修改、删除、优先级调整、截止日期提醒、统计。好处是权限和限流可以按接口配，坏处是共享代码（数据库连接池、鉴权中间件、响应封装）要重复打包。FunctionGraph 支持层（Layer），把公共依赖做成层之后，每个函数包体积明显下降，冷启动也快了一些。

冷启动是第二个坑。函数长时间不调用后第一次请求会明显变慢，而 RDS 连接又不能在函数实例里长期持有。我的处理是把连接建立放在初始化阶段并复用，同时给 APIG 侧配了合理的超时，避免用户端直接看到网关超时。

第三个坑是环境变量。数据库地址、账号、连接池大小这些必须走函数配置的环境变量，绝不能写进代码包。案例里给的 deploy.sh 会把 .env 里的值注入到函数配置，这一步很容易被跳过，结果就是本地能跑、云上 500。

还有 idempotency。新增待办如果客户端重试，会产生两条重复记录。我在端侧给每次提交带一个客户端生成的请求 ID，服务端用它做唯一约束，重试就变成幂等。这个改动很小，但能省掉大量「为什么多了一条」的排查。

最后是验收。案例提供 verify_api.sh 做端到端检查，我建议把它接进部署流程的最后一步，而不是手动跑。云函数和网关配置任何一处改错，这个脚本都能第一时间暴露出来。