鸿蒙端云联调504复盘：冷启动、超时与重试的三道坎

一次端云联调，登录接口第一次调用返回了 504。第二次、第三次还是 504。换个思路重试几次之后，接口突然恢复正常，返回了登录成功。同一套代码、同一组参数，为什么前几次失败、后几次成功？这篇文章把这次排障过程拆开，聊聊鸿蒙端云一体联调里最常见的三道坎：冷启动、超时与重试。

一、504 不等于失败

先说结论：网关返回 504，只代表网关在规定时间内没有等到后端响应，不代表后端没有执行。

云函数收到请求后会继续跑：建表、写库、签发会话凭证，这些步骤可能已经完成了。客户端看到 504 就认为失败，再点一次登录，就会重复建账号、重复发请求。排障的第一步，是先查库、查日志，确认后端到底执行到了哪一步，再决定要不要重试。

二、冷启动为什么要花几秒

挂在私有网络里的云函数，冷启动时要先挂载弹性网卡、建立到数据库的连接，实测大约需要六秒。这个时间不是代码慢，而是环境准备的固定成本。

热实例不存在这个问题：实例已经就绪，请求进来直接执行，耗时回到毫秒级。所以“第一次慢、后面快”是冷启动的典型特征，不必一上来就怀疑代码。

三、超时参数要按实测配，不能照抄示例

网关的后端超时默认常常是五秒，而冷启动就要六秒。五秒的超时配六秒的冷启动，第一次调用注定超时。

正确的做法是按实测调整两处超时：

• 云函数自身的超时，调到三十秒，给冷启动留出余量
• 网关的后端超时，调到三万毫秒，与函数侧对齐

调完之后还要重新发布接口配置，否则改的是旧配置，测的还是旧行为。很多“改了没效果”的问题，根源都在这里。

四、重试要讲幂等，否则越重试越乱

冷启动场景下重试几乎是必选项：第一次 504 就重试两到五次，大多能恢复。但重试必须配合幂等设计，否则一次超时、多次执行，库里会出现重复数据。

可行的办法有两条：

• 写操作用客户端生成的唯一标识做主键，重复写入时按主键去重，数据库层面用插入或更新同一条记录的方式兜底
• 读操作与写操作分开看：查询类接口重试没有副作用，写接口重试前先确认上一次是否已落库

“重试几次就好”和“重试几次就乱”，差别就在有没有幂等。

五、排障的三步判定法

遇到接口超时，可以按下面三步定位：

1. 先看是冷启动还是热实例：第一次慢、后续快，大概率是冷启动；每次都慢、稳定在五六秒，要看连接池与实例状态
2. 再看超时发生在第几跳：网关超时、函数超时、数据库连接超时，三者的日志位置不同，不要混在一起猜
3. 最后用一个最小的诊断函数验证：只做一次数据库查询，确认函数到数据库的链路本身是否通畅，再排查业务逻辑

三步走完，大多数 504 都能定位到冷启动、超时配置或连接池这三类原因之一。

六、从演示到生产的改造清单

教学演示为了跑通链路，往往会做几处简化，联调通过后、上生产前要逐项改掉：

• 会话凭证不要放在地址栏的查询参数里传递，改走请求头
• 会话要加过期时间，并实现刷新与撤销，不要用永不过期的凭证
• 数据库账号与密码只放在云函数环境变量里，不要写进端侧代码
• 网关认证从联调用的无认证，切到正式的签名认证
• 端侧不要明文保存敏感信息，换成本地加密存储

每一项都是小改动，但缺了任何一项，演示代码都不能直接上生产。

结尾

端云联调的 504，大多不是代码写错了，而是冷启动、超时、重试三者没有对齐：冷启动要六秒，超时只给五秒，重试又没有幂等。把超时按实测调对、把重试做成幂等、把排障拆成三步，联调就会顺很多。下一篇文章，我会聊聊端侧的状态刷新：列表改了为什么界面没变，以及列表键值里应该包含哪些可变字段。