企业官网建设流程全解析

1. 为什么Java AI应用必须做异步化与高并发设计

做Java后端这几年，最深的感受是：AI应用的接入方式，和过去写传统CRUD接口完全不是一个量级的问题。过去调一个数据库查询、调一个下游RPC，响应时间能到200毫秒我们都嫌慢。但AI应用不一样，你调一个大模型推理接口，慢的时候七八秒，甚至十几秒都很正常。如果还是用老思路——来一个请求就占一个Tomcat线程，线程阻塞在那里等AI返回，那系统容量立刻就被打穿。一个4核8G的实例，200个并发请求进来，Tomcat默认200个线程全部被挂起，CPU利用率看着不高，但新请求全部排队，整个服务就像死了一样。

这就是AI应用异步化与高并发设计的核心命题：AI接口的耗时长、波动大、成本高，决定了我们不能用同步阻塞的方式来承接流量。我在接手某智能客服项目时，线上出现过一次非常典型的故障：大模型供应商侧偶发抖动，单次调用从2秒飙升到15秒，结果所有线程被占满，健康检查探针也超时，服务被负载均衡摘掉，整段业务挂了接近40分钟。事后复盘，根因只有一个——我们把AI调用直接写在了请求线程里，没有做任何异步化和隔离。那次故障之后，我花了两周时间重构了整个调用链路，也是踩了不少坑才把方案跑稳。

这篇文章适合正在做Java AI应用、AI Agent编排、LangChain二次开发、或者打算把大模型能力接入现有业务系统的后端工程师阅读。我会从异步方案选型、高并发防护、限流降级、以及一套可落地的实操案例几个方面，把AI应用高并发设计里真正要命的技术细节讲透。

先说结论：AI应用的高并发设计，不能照搬传统互联网的套路，也不能完全不用传统套路。它的难点在于既要处理大模型接口的“慢”，又要应对多Agent协作带来的“复杂”，还要考虑API成本与限流约束。理解了这三者的关系，后面的设计才有方向。

2. 异步化方案选型：CompletableFuture、虚拟线程还是消息队列

2.1 三种主流异步方案的适配场景对比

上生产之前，我花了大量时间做方案调研。当前Java生态里能用的异步化手段无外乎三种：CompletableFuture异步编排、虚拟线程（Java 21+）、消息队列异步解耦。这三个方案并不是互斥关系，而是针对不同层次的问题。

先给一张我整理过的对比表，看完基本心里有数：

选择的关键在于回答一个问题：用户发起的这次请求，是必须在线等到结果（同步返回场景），还是可以放在后台慢慢跑（异步结果场景）？

如果是同步场景，比如用户在网页里发了一句消息，需要实时拿到AI回复，那CompletableFuture或者虚拟线程是主力。在Java 17以下的项目里，CompletableFuture是绝对主力；如果已经上了Java 21，虚拟线程能大幅简化代码——你不需要各种thenCompose的链式调用，直接用同步写法也能获得高并发能力。

如果是异步场景，比如上传一份文档让AI分析，分析结果通过回调或者前端轮询获取，那消息队列是最合适的。把任务丢进MQ，消费者慢慢消费，天然具备削峰填谷和失败重试的能力，不会因为AI接口变慢而拖垮主服务。

这里我特别想提醒一个误区：不要一上来就选消息队列。很多人觉得异步化=消息队列，其实不对。MQ引入之后，系统复杂度是成倍增加的：消息顺序问题、消费幂等问题、延迟问题、消息堆积告警，每一个都要处理。我见过不少团队，明明是个同步问答的场景，硬是绕过MQ又加了一层状态轮询，结果链路绕了一整圈，延迟比原来还高，排查问题也困难得多。

2.2 CompletableFuture的实用技巧与深坑

如果你和我一样主力使用CompletableFuture，有几个细节是必须掌握的。

第一，必须显式传入线程池参数。CompletableFuture.supplyAsync()这个静态方法有两个重载版本，不传Executor的情况下，它会使用ForkJoinPool.commonPool。在Java 8的默认配置里，commonPool的并行度是CPU核数-1，而且整个JVM里所有使用commonPool的代码共享这个线程池。AI调用是阻塞型任务，一旦多个业务都在往commonPool里塞任务，线程池很快耗尽，届时不光是AI功能卡死，连其他依赖commonPool的代码（比如Stream的并行流）也会跟着遭殃。所以生产环境里，每一个supplyAsync，都给我显式传自己的业务线程池。

第二，异常处理必须层层织密。CompletableFuture的异步任务在子线程里抛异常，不会直接炸到主线程，而是会保存在这个Future的内部状态里。如果你没有调用exceptionally或handle来处理，这个异常就会“静默吞掉”——后续代码看起来没报错，结果却是null，排查起来极其痛苦。我的习惯是：每一层编排链，至少挂一个exceptionally兜底，在最外层再挂一个whenComplete来记录日志和告警。

第三，串行和并行要分清楚。多Agent协作的场景里，有些环节必须严格串行（比如先做意图识别，再根据意图决定调用哪个工具），有些环节可以并行（比如同时召回知识库文档 + 检索用户历史记录）。串行用thenCompose，并行用allOf。

这里有一个经常被搞混的点：thenCompose和thenApply的区别。thenApply是对上一个阶段的返回值做同步转换，返回的是普通值；thenCompose是返回一个新的CompletableFuture，相当于把两个异步任务“扁平化”串联。在AI编排场景，几乎全部要用thenCompose，因为下一步往往也是异步调用。

2.3 虚拟线程：Java 21带来的新解法

如果你的项目已经升级到了Java 21，我强烈建议尝试虚拟线程。它的原理不展开了，简单理解就是JVM自己管理大量轻量级线程，一个阻塞操作挂起时，底层平台线程可以立即切去执行别的虚拟线程，非常省资源。

虚拟线程给AI应用带来的最大价值，是代码可以回到同步写法，但并发能力不减。比如你调一个AI接口，普通线程版代码长这样：

public ChatResponse chat(String userMessage) { // 这是一个阻塞调用，占2秒 String result = llmClient.call(userMessage); return new ChatResponse(result); }

在Tomcat线程模型下，这个请求会占据一个200ms~15s的线程资源。但如果我把下游调用改造成虚拟线程执行，就能用相同的内存支撑高得多的并发量。Java 21里可以用Executors.newVirtualThreadPerTaskExecutor()来获得一个虚拟线程执行器，也可以直接用Thread.startVirtualThread()启动。

实践下来，虚拟线程有两个需要注意的坑。第一，它在synchronized块里可能会pin住底层平台线程，一旦大量虚拟线程在synchronized块里阻塞，效果反而比普通线程池差。AI应用要尽量避免在持锁状态下调用外部接口。第二，不要用线程池去池化虚拟线程——虚拟线程本身就很轻量，池化反而带来不必要的排队和性能损耗。这个我后面在排查章节详细说。

我的线上方案是“组合拳”：请求网关层用CompletableFuture做异步编排和超时控制，最底层的AI调用用虚拟线程执行器承接阻塞等待，中间用信号量做并发保护。这样既有编排的灵活性，又有虚拟线程的轻量性。

3. 高并发防护：线程池、限流与缓存的配合设计

3.1 线程池参数设计：AI调用是典型的IO密集型

高并发设计的第一步，是给异步任务一个合理的线程池。AI调用是典型的IO密集型任务——CPU很少干活，绝大部分时间都在等外部接口返回。IO密集型线程池的核心线程数计算公式是：

线程数 = CPU核数 / (1 - 阻塞系数)

阻塞系数通常取0.8~0.9。以一台4核机器为例，如果阻塞系数按0.9算，线程数 = 4 / (1-0.9) = 40。但这里的关键并不在于单台机器的线程数，而在于避免把这种线程池用在非AI场景。我见过一个团队，把AI调用线程池的核心线程数配置成200，然后在同一台机器上还部署了普通RPC服务，结果AI高峰期把CPU争抢得厉害，普通接口的RT也跟着飙高。

更稳妥的做法是给AI调用单独建一个线程池，并且做好容量评估。我服务里实际的配置示例（基于Spring Boot）：

@Bean("aiExecutor") public ThreadPoolTaskExecutor aiExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(20); executor.setMaxPoolSize(80); executor.setQueueCapacity(200); executor.setKeepAliveSeconds(60); executor.setThreadNamePrefix("ai-call-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; }

这里我重点解释两个容易被忽视的参数。queueCapacity别设太大，一旦队列满了，触发CallerRunsPolicy后任务会在调用线程执行，至少不会把任务直接丢弃。CallerRunsPolicy的核心含义是：当线程池忙不过来时，任务由提交任务的线程自己执行，实现一种“慢下来”的天然背压。这个策略在AI场景很实用，它不会让用户请求直接失败，只是会阻塞调用方线程，代价是响应变慢，但至少不丢数据。

3.2 限流设计：既要防A供应商，也要防自己的成本

AI应用和普通应用最大的区别在于：底层大模型API通常都有严格的并发和速率限制，而且按Token计费。这就意味着限流不能只看QPS，还要考虑Token消耗速率。

我的做法是双维度限流。第一层是并发信号量限流，用Semaphore控制同时进行中的AI调用数。比如某大模型账户的并发上限是20，那我就设置Semaphore(15)，留出15的余量给重试和其他突发。第二层是速率限流，用 Guava RateLimiter 按每秒请求数和每秒Token消耗数做双重校验。

为什么按Token限流？因为用户输入的prompt长度是变化极大的。一个用户可能只发“你好”，另一个用户可能粘了一段两千字的文档。单纯按请求数限流，根本没法防止Token消耗超过账户限制。更实用的方案是：在调用前估算本请求的Token消耗（输入字符数/3 + 输出最大Token数），结合限流器里的剩余Token配额做控制。超了就把请求排队或者降级。

3.3 缓存设计：AI响应到底能不能缓存

很多人以为AI接口的响应是纯随机生成的，没法缓存。我在实际项目里发现，这个认知是片面的。

诚然，LLM是生成式模型，同样的输入两次结果可能不同。但在大量真实场景中，很多问题有着确定性答案的，或者允许语义近似的稳定回答。举例说明，智能客服系统里，用户问“怎么退款”和“退款流程是什么”，如果系统命中了知识库里的同一篇退款文档，那么用固定模板生成的回答，完全可以是稳定、一致的。这类内容做缓存，既降低API成本，又降低响应延迟。

实现上，我会用两级缓存策略：

1. 精确匹配缓存：问题文本完全一致（去掉空格、统一大小写之后）时，直接命中Redis缓存。缓存键的粒度要细，至少包含模型名、提示词版本、温度参数、问题原文的哈希值。
2. 语义相似缓存：对问题做embedding向量化，存到向量数据库里。当新请求的embedding与缓存内容相似度超过0.95时，直接复用缓存的回答。相似度阈值要调得很保守，避免因为语义误差给出错误回答。

不过要注意缓存污染的防控。AI应用中，缓存键如果包含了用户ID、对话历史这类个性化因素，那缓存命中率会直线下降，得不偿失。我的经验是：能进缓存的，一定是那些与个性化信息无关、结果高度稳定的“公共问答”。

3.4 熔断降级：AI服务抖动时的自保机制

高并发设计绕不开的还有熔断降级。大模型供应商的API稳定性，说实话，比我接触过的多数内部微服务要差。超时、5xx、限流报错，都是家常便饭。所以我给AI调用层加了一套基于Resilience4j的熔断保护。

熔断的核心参数设计：

resilience4j.circuitbreaker: instances: llmCall: registerHealthIndicator: true slidingWindowSize: 20 minimumNumberOfCalls: 5 permittedNumberOfCallsInHalfOpenState: 3 automaticTransitionFromOpenToHalfOpen: true failureRateThreshold: 60 waitDurationInOpenState: 30s

含义是：最近20次调用中，如果失败率超过60%，就打开熔断器，不再调用AI接口，直接走降级逻辑。30秒后进入半开状态，放3个试探请求，如果成功就恢复，失败则重新打开。

降级策略按场景设计三档：第一档，保守回答——返回预设的提示语，比如“当前服务繁忙，请稍后再试”；第二档，简化模型——把大模型调用降级为小模型调用，比如从GPT-4降到轻量模型；第三档，本地规则兜底——如果业务本身有低频但可用的规则引擎逻辑，就直接走规则返回。

这里特别提醒一点：降级逻辑本身也要做防护。很多团队把降级逻辑写成调用另一个外部服务，结果主服务熔断后，降级服务被打崩，雪崩效应反而更严重。降级方案应该优先选择本地可完成的逻辑。

4. 实操：一个AI Agent异步编排的落地流程

4.1 业务场景描述

拿我最近做的一个项目举例：一个“智能助手”服务，支持用户多轮对话。服务内部有多个Agent协同工作：意图识别Agent、知识库检索Agent、工具调用Agent、最终生成Agent。

整个请求链路是这样的：

1. 用户发送消息。
2. 服务并行执行“意图识别”和“用户历史摘要”。
3. 根据意图决定下一步：如果意图是查知识库，则召回到Top-K文档；如果意图是查订单，则调用订单工具。
4. 将“意图 + 历史摘要 + 知识库文档/工具结果 + 用户消息”一并交给生成Agent，产出最终回复。
5. 最后做敏感内容过滤和日志记录。

在这个场景里，步骤2和3存在并行分支，步骤4依赖前面所有结果，整个链路如果串行执行，用户等待时间将等于各个Agent耗时之和，动辄8~10秒。如果做异步并行和串行编排，目标是把总耗时压到4秒以内。

4.2 异步编排的落地代码示例

下面是我在实际项目中用到的核心编排逻辑（做了简化脱敏）：

public ChatResponse handleChatRequest(UserRequest request) { // 1. 并行执行：意图识别 + 用户历史摘要 CompletableFuture<String> intentFuture = CompletableFuture .supplyAsync(() -> agentService.recognizeIntent(request.getText()), intentExecutor); CompletableFuture<String> historyFuture = CompletableFuture .supplyAsync(() -> agentService.summarizeHistory(request.getUserId()), historyExecutor); // 2. 等待意图结果，再根据意图做分支查询 CompletableFuture<List<ContextDoc>> contextFuture = intentFuture .thenCompose(intent -> { if ("KNOWLEDGE_BASE".equals(intent)) { return CompletableFuture .supplyAsync(() -> agentService.searchKnowledge(request.getText()), searchExecutor); } else if ("ORDER_STATUS".equals(intent)) { return CompletableFuture .supplyAsync(() -> agentService.queryOrder(request.getUserId()), searchExecutor); } return CompletableFuture.completedFuture(Collections.emptyList()); }); // 3. 合并历史摘要和上下文文档，生成最终结果 CompletableFuture<ChatResponse> resultFuture = historyFuture .thenCombine(contextFuture, (history, docs) -> new GenerationContext(history, docs)) .thenCompose(ctx -> CompletableFuture .supplyAsync(() -> agentService.generate(request.getText(), ctx), llmExecutor)); // 4. 整体超时控制，避免无限等下去 return resultFuture.orTimeout(8, TimeUnit.SECONDS) .exceptionally(ex -> { log.error("agent orchestration failed, user={}", request.getUserId(), ex); return ChatResponse.fallback("当前服务繁忙，请稍后再试"); }) .join(); }

这段代码有几个要点：

• 每个supplyAsync都显式指定了独立的Executor，避免互相挤占。
• 意图识别和历史摘要并行执行（第5~11行），这是压时间的关键之一。
• 意图分支通过thenCompose串接，既保持了代码可读性，又在同一个Future链里传递上下文。
• thenCombine把两个异步结果合并成生成阶段的输入，等于把并行分支汇合。
• 最外层用orTimeout实现整体超时，避免任何一条链路过慢拖死用户请求。
• exceptionally作为兜底，保证任何环节抛异常，用户都能拿到一个降级响应，而不是一个莫名其妙的500。

4.3 参数计算与实际压测数据

这个服务上线前，压测是我一行一行调出来的。服务部署在8核16G的容器上，Java 17，CompletableFuture异步编排。线程池参数推演过程如下：

• 目标支撑 100 QPS 的并发请求（这是业务方给的一个比较激进的指标）。
• 单请求平均耗时假设4秒（AI生成是大头，占3秒左右，意图识别+检索合计约1秒）。
• 同时处于活跃状态的任务数 = 100 QPS × 4秒 = 400个。
• 这400个任务里，意图识别的并发量最高，约等于 100 QPS × 0.3秒/次 = 30；但因为每个任务都很快，线程数设12就够。
• 检索线程池因为涉及数据库和外部调用，耗时大约200ms~500ms，并发约50，核心线程数设16。
• 生成Agent线程池是关键，耗时3秒以上，100 QPS × 3秒 = 300并发，这个量非常吓人，单靠线程池不能扛，必须结合信号量限流把同时调用大模型的并发压到20以下。

实测下来，这套配置稳定支撑 80 QPS 无降级，响应P95在4.2秒左右，P99在6.8秒。能达到这个水平，靠的其实不是某一个线程池，而是“并行编排 + 并发限制”共同作用的结果——既让请求在这个服务内部尽量并行处理，又不会对一个并发放开但外部供应商根本承受不住的底层接口无限放大流量。

4.4 异步线程上下文传递的一个实战经验

异步化之后，另一个容易踩的坑是上下文传递。普通的Servlet请求里，TraceId、租户ID、用户ID都存在ThreadLocal里。但在CompletableFuture的子线程里，ThreadLocal默认是拿不到主线程的内容的。

我当时的方案是引入一个ContextAwareRunnable包装器，在每次提交异步任务前，把主线程的关键上下文快照复制一套出来，任务执行时再填充进去。

public class ContextAwareTask<T> { private final Map<String, String> contextSnapshot; private final Supplier<T> task; public ContextAwareTask(Supplier<T> task) { this.contextSnapshot = ContextHolder.snapshot(); this.task = task; } public T execute() { Map<String, String> oldContext = ContextHolder.snapshot(); ContextHolder.restore(contextSnapshot); try { return task.get(); } finally { ContextHolder.restore(oldContext); } } }

当然这是一个简化实现，生产环境还建议直接用TransmittableThreadLocal这个库，它专门解决了线程池场景下ThreadLocal值传递的问题，实现更完善，美团开源的那个。如果你不想引入额外依赖，手动快照再恢复的做法也能凑合，但一定要记得在finally里恢复上下文，否则你的任务A跑完，下一个reuse这个线程的任务B，就会拿到A的上下文，这个bug还特别难查。

5. 常见问题与排查经验实录

5.1 线程池被打满，接口全部超时

这是AI应用上线初期最典型的故障。现象：接口偶尔返回超时，从监控上看线程池队列一路涨到队列上限，触发拒绝策略。

排查三步走：

1. 查线程池的活跃线程数和队列长度（通过Spring Actuator 的/actuator/metrics或者JMX）。
2. 看AI供应商侧的平均响应时间，如果供应商平均RT从2秒变成8秒，那大概率是供应商抖动。
3. 看是否有异常的慢SQL或者其他阻塞逻辑占用了线程池资源。

解决这一类问题的核心思路是隔离+降级。不能把AI调用的线程池和普通业务线程池混在一起（否则AI供应商抖动会污染全站），并且在检测到线程池活跃度超过80%时，果断对新请求降级，而不是让所有请求都积液在队列里等待。我后来做了线程池监控告警：队列使用率超过70%时触发钉钉告警，90%触发降级。

5.2 异步编排中异常被静默吞掉

这个问题在CompletableFuture场景特别阴险。有一次我们上线一个功能，用户反馈老是收不到结果，但服务日志里没有任何异常。排查半天发现，问题是某个thenApply里抛了一个NPE，但这个异常只被保存在了Future里，后续我又用join()去取，但代码逻辑没有正确处理，结果整个链路直接返回了一个空对象，前端渲染成一个“空回复”。

解决的方法，一是强制在所有Future链末端统一挂whenComplete，打印错误日志；二是全局的异步任务入口统一封装一个AsyncUtils.run方法，在这个方法里包装异常捕获，确保任何异常至少都有日志输出。相信我，异步代码里的日志是你半夜排查故障唯一的救命稻草，嫌日志多、关了warning日志，最后吃亏的一定是你自己。

5.3 流式输出场景下的坑：readTimeout要单独设置

很多AI应用不只是简单的一问一答，而是需要流式输出（SSE）——用户看到一个字一个字蹦出来的效果。这里有个非常容易踩的坑：HTTP客户端的connectTimeout和readTimeout设置。流式输出过程中，模型生成一句话可能需要十几秒，但两个数据包之间的间隔可能就有20秒（长思考场景）。如果你按普通接口设置了readTimeout=10s，那么SSE长连接会在10秒后直接被客户端掐断，前端表现为：“回复了一小段就停了”。

我的建议是，流式请求的底层HTTP客户端不要设置固定的readTimeout，而是用“空闲超时”的语义来取代。比如OkHttp的readTimeout(0, TimeUnit.SECONDS)配合pingInterval做心跳保活。同时要区分“首字延迟”和“字间延迟”，首字延迟超过5秒可以放弃，字间延迟超过60秒可以认为连接已死。这些都应该做成可配置的，因为不同模型供应商的节奏差异非常大。

5.4 重试机制：AI接口幂等性背后的陷阱

AI接口调用失败后，很多人第一反应是重试。这个思路要非常小心。通用服务重试是安全的，但AI生成接口的重试存在三个问题：

• 成本翻倍：一次超时重试，可能意味着你为同一个问题付了两次费。
• 时间翻倍：一个8秒的调用超时后，再重试一次8秒，用户等待翻倍。
• 结果不可控：LLM没有严格幂等性，重试返回的内容可能和第一次完全不同（虽然是同一个问题），可能会前后矛盾。

我的重试经验是：只对某些特定错误重试，比如HTTP 5xx、429限流、以及网络超时；对HTTP 400这种参数错误绝不重试，重试多少次结果都是一样的。重试次数默认1次，上限2次，且使用指数退避（第一次等1秒，第二次等2秒）。更重要的是，重试和降级要分清楚——重试是尝试同样的链路，降级是切换到一个成本更低但保证响应的方案。如果第一次调用就超时，我宁可降级到小模型，也不原样重试大模型。

5.5 虚拟线程性能陷阱：synchronized与池化

最后单独讲一下虚拟线程的坑。Java 21的虚拟线程引入之后，很多团队非常兴奋，直接把Tomcat的线程替换掉。但在一个采访项目里，我们用虚拟线程做深度压测时，发现性能并没有明显提升，甚至某些场景倒退。

复盘发现的根因有两个。

第一，虚拟线程在遇到synchronized关键字的重量级锁时，会发生“pin住”，导致底层平台线程被占用，无法切换去做其他虚拟线程。解决办法是用ReentrantLock替换synchronized，代码层面少用同步块，特别是不要在锁保护的代码块里去调用AI接口。

第二，虚拟线程根本不需要池化。很多人习惯性地Executors.newFixedThreadPool(100)来限制并发，但这个习惯从平台线程迁移到虚拟线程后是反模式。虚拟线程的价值就是创建成本足够低，开一个用一次，用完就扔。如果硬要限制并发，应该用信号量（Semaphore）而不是线程池，因为线程是“无限”的，并发限制应该落在业务层面。

经历了那次压测，我对虚拟线程的使用原则变成了：能用虚拟线程的地方绝不手写线程池，能用信号量控制的绝不用队列堆积。这套思路让代码简洁很多，并发控制也更精准。

6. 最后再分享几条实践经验

这套异步化与高并发设计，我前后迭代了三版才稳定下来。第一版是纯CompletableFuture编排，踩了线程池泛滥的坑；第二版引入熔断限流和降级，把稳定性拉上来了；第三版引入虚拟线程做底层调用，并发能力又上了一个台阶。

如果你现在刚开始做Java AI应用，我的建议顺序是这样的：先把线程池、超时、重试、降级这些基础打牢，确保面对AI接口抖动时系统能自保；再引入CompletableFuture做并行编排，把响应时间压下来；架构稳定后再考虑Java 21的虚拟线程、消息队列解耦这类更进阶的手段。别一上来就把所有工具全堆上去，复杂度本身也是成本。

还有一个容易被忽略的点：AI应用的监控指标和传统应用不一样。传统应用重点盯QPS、RT、错误率；AI应用还要额外盯Token消耗速率、缓存命中率、降级触发次数、熔断状态切换次数、可用性SLA这些指标。特别是Token消耗，直接和成本挂钩，我建议做成大屏实时展示，让团队每个人都能看到每一次降级、每一次重试花了多少钱。成本意识有了，很多乱调用、乱重试的毛病也会收敛很多。

最后一条是个人体会：无论异步化设计得多完善，AI应用都不是一个纯技术问题。模型选型、Prompt设计、降级话术的编写，同样决定用户体验。我们做技术设计时，要始终站在用户的真实等待感上去考虑——一个花了4秒正常生成的结果，和一个1秒返回的“当前繁忙”降级提醒，后者不一定比前者更好。这也是我为什么坚持把降级响应也做得有温度的原因。技术上的每个选择，最终都要回到用户的真实感受上去验证。