不要再硬编码超时时间了

Lobsters Hottest 新闻

摘要

一篇开发者的吐槽,认为 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)。* 网络以及我们基于它打造的工具,是为所有人服务的。让我们用行动体现这一点。

相似文章

慢速软件:为高延迟系统开发辩护

Lobsters Hottest

文章认为,AI编程加速了开发速度与系统重要性的脱钩,导致关键系统变得脆弱且故障波及范围广,并倡导实施强制谨慎设计的‘慢速软件’。

关于API的一通吐槽

Lobsters Hottest

一位开发者在博客中吐槽了在自动化Vori的入职流程时遇到的常见API设计问题,包括文档访问受限、缺少OpenAPI规范、缺乏自助凭证签发机制以及凭证身份处理不佳等。

我们不断重造的车轮

Lobsters Hottest

一篇论述软件工程师反复重造已被充分解决的基础设施(如身份验证、后台任务、速率限制和功能开关)的文章,用自定义代码换取经过验证的解决方案,却不得不自行维护和调试这些代码。