靠 http 接口的超时 如果你套了 nginx nginx 那边超时也得跟着设置 很麻烦的 不如 redis 然后前端轮询各种都随你

方案 2 ，如果是自己的小玩具 无脑等待就好了， 一般生图这种都是任务状态 被动触发的

websocket 之类的长连接推送进度。进页面查询自己的 taskID ，根据 id 和后端建立 websocket 连接获取实时进度

肯定 1 啊，web 框架对每个 controller 调用不还是用的 go 协程。你 controller 等待生成时是直接 io 卡死在那，go 的调度器会自动处理的。你费那么大劲用 redis 或 channel 根本没任何必要（除非有什么持久化或者生成一半要取消之类的需求） 你唯一要考虑的就是调用请求的客户端还有你 web 服务器前的网关的最大超时时间

2 每个 user agent 每层 gateway 都可能有自己的 timeout ，不像 2 这样 你还要相信别的很多东西

搞成异步的，完成了之后主动推送一个事件，然后提供图片 URL 。

你不考虑用户因为网络波动导致直接断开连接吗？那不是一切重来。

这首先是一个接口设计问题

小 demo 就同步，怎么简单怎么来。我写 demo 不爱用 web ，直接命令行跑起来就算。 生产环境必须异步。 1 ，负载能力决定了任务需要队列，耗时包含了排队时间，不可能一定是 30s 的。任务的逻辑超时时间取决于业务决策并且可能天天变化。 2 ，技术上一个链接的超时时间取决于链路中多个组件的设置。客户端、代理、网关、应用。。。远不如短连接+异步来得简洁稳固。 3 ，API 和 task 资源池解耦，甚至我们 API 和调度也解耦了。这样 API 的可靠性增加，task 计算池的弹性增加。 4 ，对服务失效有更高的状态恢复能力。 5 ，接口层 task 状态可推可拉，对客户端也挺灵活挺友好。 6 ，整个系统的吞吐量瓶颈几乎只剩一个：task 计算池了。API 和调度都很难形成瓶颈了。

如果任务比较多，就搞一个异步任务中心，这种长时间的多个异步任务交给它来执行，异步任务中心执行完了在通知你的 Go 程序，比如用 Go 写个 task cron 异步执行系统或找个开源的