FunctionGraph 第一次上线，我栽在超时和权限上

FunctionGraph 的卖点很明确：不养服务器，写好函数就能跑。第一次把本地小接口搬上去时，我栽的不是语法，而是这三件事叠在一起：

• 超时时间按默认值，冷启动一来就失败
• 委托权限只开了函数本身，没开它要访问的服务
• 日志在另一个地方，当时页面上看不到完整报错

下面按能复现的顺序写。目标不是讲架构，是让下一次少花一小时。

1. 先把范围收小

第一次不要上复杂编排。我用的最小集是：

• 运行时：Python
• 触发方式：先用控制台测试事件，再考虑 HTTP
• 外部依赖：只访问一个云服务，或先不访问任何云服务
• 返回：固定 JSON，不在函数里做重活

能稳定返回 {"ok": true}，再加业务。

2. 实际走过的步骤

1. 创建函数，选好运行时和区域，区域必须和要访问的资源一致。
2. 在线编辑器先放 20 行代码，不要直接传大 zip。
3. 配测试事件，点测试，看状态码和返回体。
4. 失败后先看执行超时，再看错误类型，最后才去翻代码。
5. 需要访问 OBS、数据库或其他云服务时，再配委托权限，不要一上来勾 FullAccess。

控制台测试通过，只说明「这种输入能跑」。不等于线上 HTTP 触发、并发和冷启动都没问题。

3. 三个最常见的失败

超时
默认超时偏保守。冷启动、拉依赖、第一次建连接，都可能刚好超掉。表现是测试失败，代码在本地却很快。先把超时调到能覆盖冷启动的范围，再优化初始化，把 SDK 客户端放到全局，避免每次请求都新建。

权限
函数执行身份是委托，不是你在控制台点按钮的那个账号。函数能创建，不代表它能读 OBS、写日志或调其他 API。缺权限时错误信息有时只是 Access Denied，不会告诉你缺哪一条。按最小权限加，加一条测一次。

日志不在眼前
返回体经常只有一句失败。真正的 traceback 在日志服务里。不先打开日志，就会在编辑器里反复改同一处。建议一创建函数就确认日志采集是开的，测一次就去对时间戳。

4. 我现在用的检查顺序

调用失败时按这个顺序，不先改业务代码：

1. 区域是否和资源一致
2. 超时是否覆盖冷启动
3. 内存是否过小导致变慢、变超时
4. 委托是否包含目标服务的最小动作
5. 日志里的第一行异常，而不是返回体那句摘要
6. 依赖包是否打进 zip，有没有把无用的大文件一起传上去

前四项对了，很多「代码明明没问题」会消失。

5. 希望产品更好用的地方

1. 创建函数向导里用一句话提示：超时要覆盖冷启动，委托不等于登录账号权限。
2. 测试结果页直接展示最近一次日志的关键异常行，少跳一层。
3. 权限缺省时给出「可能缺少哪类动作」的短提示，而不是只回 Access Denied。
4. 提供一个官方最小模板：带日志、带超时说明、带只读访问示例。
5. HTTP 触发开通后，在函数详情展示最近几次状态码，方便判断是代码问题还是网关问题。

6. 小结

FunctionGraph 适合把小接口和事件处理很快送到云上。第一次上线最容易高估「保存成功」，低估「运行身份和超时」。

先让空函数稳定返回，再加依赖，最后再谈并发和编排。
这篇对应的改进建议也可以单独提到云声。如果你有更干净的冷启动和权限配法，欢迎直接评论运行时和超时设置。