不要再硬编码超时时间了
摘要
一篇开发者的吐槽,认为 vercel-labs 的技能安装器和 Docker Gordon 这类工具内置了无法配置的硬编码超时设置,导致网络较慢环境中的用户无法正常使用,并主张每个超时设置都应安全、有文档说明,且允许用户覆盖。
<p><a href="https://lobste.rs/s/qa0owz/stop_hardcoding_your_timeouts">评论</a></p>
查看缓存全文
缓存时间: 2026/11/02 21:52
# 别再硬编码超时时间了
来源:https://alfy.blog/2026/04/23/stop-hardcoding-your-timeouts.html
*一个开发者对只为某一种网络环境打造的工具的吐槽*
最近,**硬编码的超时时间**快把我逼疯了。这些悄无声息、随意设定、无法配置的时间限制,被开发者直接写死在工具里,而这些开发者显然一辈子都没为任何事情等过超过 200 毫秒。
让我说说我这一周的遭遇。
### `skills`包和 60 秒的克隆时限
如今,编程智能体无处不在,大家都在用技能。添加技能的流行方式是使用 vercel\-labs 开发的包,而首选的技能合集是**awesome\-copilot**,一个经过精心整理的技能集合,撰文时已获得 30K\+ 星标。但我用不了它。这个仓库太大,`npx skills`安装程序直接卡死,然后退出。
从二月份起,vercel\-labs/skills 仓库里就有一个关于此问题的未关闭议题 \#278 (https://github.com/vercel-labs/skills/issues/278),但一直没人回应。我很乐意提交一个 PR,自己修好它。我只是需要有人承认这个问题存在。
有配置选项吗?有`--timeout`参数吗?有环境变量吗?没有,什么都没有。
我找到的变通办法是什么?先手动克隆仓库,再从本地副本安装。大体上能用。但现在,`skills-lock.json`指向了我电脑上的一个路径。我的同事没法用。而且,每次想更新技能时,我还得更新本地副本。一个变通办法又带来了一堆其他问题。
### Docker Gordon 和 2 分钟死亡倒计时
接着是 Docker Gordon,也就是 Docker 内置的 AI 调试助手。这个想法很实用。当时我正在逐步排查一个容器构建问题,这类问题需要反复迭代:修改、重新构建、检查,然后重复。我之前从没用过 Gordon,但错误出现时,系统建议我试试 Gordon,于是我就试了。
但 Gordon 有一个硬性限制:如果你的容器没能在**两分钟**内完成构建,它就会放弃。会话终止。你得从头再来。
如果你的环境速度很快,缓存已经预热,基础镜像也已经拉取好了,两分钟的构建时间听起来可能绰绰有余。但如果你要通过较慢的连接拉取一个全新的基础镜像呢?如果你正在调试一个包含多个庞大镜像层的多阶段构建呢?别想了。Gordon 早就不等你了。
这个限制无法配置。没有`GORDON_TIMEOUT=600`这样的环境变量。没有`--build-timeout`参数。什么都没有。这个工具就是认定两分钟已经长得没边了,如果你需要更多时间,那是你自己的问题。
### 这种模式快把我逼疯了
开发者往往使用高速电脑,在拥有千兆网络的办公室或家中工作,所在城市也有世界一流的基础设施。他们根据自己的体验,为工具设定默认超时时间。然后,他们把这些工具发布给全世界,却不提供任何可调整的选项。
问题在于,超时机制*确实需要*存在。无限等待不好。进程挂起不好。我不是反对超时机制。我反对的是**无法配置的**超时机制。反对的是那种隐含的信息:*如果你没法在 60 秒内完成,那就是你的环境有问题,而不是我的假设有问题。*
超时机制应该:
- 为常见情况提供一个**安全的默认值**
- **在文档中明确说明**,让用户知道它的存在
- **允许覆盖默认值**,通过参数、环境变量、配置文件,*什么方式都行*
这并不难。这是对用户的尊重。
### 世界不是弗吉尼亚州的一座数据中心
我在开罗写下这些文字。我的网络还不错,比世界上很多地方都好。但它不是上下行对称的 1 Gbps 光纤。我的设备也没有和 npm 注册表镜像部署在同一个机房。对大型仓库执行`git clone`需要时间。拉取 Docker 镜像需要时间。这些不是故障。这是物理现实。
当你的工具在 60 秒后悄无声息地退出,而且用户没有任何办法修改这个限制时,你打造的就不是一个面向全世界的工具。你打造的是一个只适合自己办公室的工具。
这件事的重要性,远超大多数开发者所承认的程度。全球开发者社区并不只在旧金山、阿姆斯特丹或伦敦。它也在拉各斯、卡拉奇、开罗。那里的人们使用 4G 连接、共享宽带,所用网络有着实实在在的延迟,因为最近的 CDN 边缘节点距离他们是 50 毫秒,而不是 5 毫秒。
当你假设用户拥有高速网络时,你做出的并不是一个中立的技术决定。你是在表明,谁的体验才值得重视。
我不认为有人是故意这么做的。我觉得这是一个盲点。你的网络很快,所以 60 秒的超时限制让你觉得很宽裕。你的电脑性能强劲,所以 2 分钟的构建时限看起来绰绰有余。
但拜托了:在你发布一个带有超时限制的工具之前,先问问自己:
- **如果用户的网络连接比较慢呢?**
- **如果他们的仓库比我的更大呢?**
- **如果他们正在调试一个缓慢的过程,而这恰恰就是调试的目的呢?**
然后,加一个配置选项。一个环境变量。一个参数。只需如此,就能让“这个工具我用不了”变成“这个工具我能用”。
正如 Bruce Lawson 曾经说过的:*这是万维网(World Wide Web),不是富裕西方网(Wealthy Western Web)。*
网络以及我们基于它打造的工具,是为所有人服务的。让我们用行动体现这一点。
相似文章
当工具调用超时,你的智能体如何知道它是否真的执行了?
一位从业者提问:智能体框架应如何处理写操作工具的超时?需要权衡幂等键、读回验证以及当下游 API 不支持幂等时的人工介入等方案。
慢速软件:为高延迟系统开发辩护
文章认为,AI编程加速了开发速度与系统重要性的脱钩,导致关键系统变得脆弱且故障波及范围广,并倡导实施强制谨慎设计的‘慢速软件’。
关于API的一通吐槽
一位开发者在博客中吐槽了在自动化Vori的入职流程时遇到的常见API设计问题,包括文档访问受限、缺少OpenAPI规范、缺乏自助凭证签发机制以及凭证身份处理不佳等。
按会话限制工具重试次数,帮我避免了失控的智能体费用
一位开发者分享了关于按会话而非按单次调用限制工具重试次数的教训,以防不稳定的端点导致费用失控,并建议为每个会话设定重试预算,一旦耗尽就果断报错。
我们不断重造的车轮
一篇论述软件工程师反复重造已被充分解决的基础设施(如身份验证、后台任务、速率限制和功能开关)的文章,用自定义代码换取经过验证的解决方案,却不得不自行维护和调试这些代码。