异步服务调优时容易踩到哪些坑异步并不等于自动高并发。把同步函数包进协程、把并发数调大看起来像给系统装上涡轮实际可能只是让更多请求一起堵在窄门口。调优前应先分清时间花在排队、计算还是外部等待总耗时是一张成绩单不是故障定位图。先观察请求经过的几段路为入口排队、检索、模型调用、数据库访问和输出组装分别记录时长与错误类别。注意用同一请求标识串起这些事件否则多个协程交错后日志只会像猫踩过键盘。观察时还要记录队列长度、取消数量、连接池使用情况和资源限制。它们不直接说明“该调哪个参数”却能帮助判断是上游突发、下游变慢还是本地计算占住了事件循环。对 CPU 密集型工作例如大批量文本预处理、复杂重排或压缩不能假定它会因为写在协程里就自动让路。必要时把工作交给进程池、独立服务或可控线程池并限制提交数量。反过来外部网络等待适合异步客户端和连接复用但也要设置连接、读取和整体超时。没有超时的异步调用就像让延迟去遛猫它想回来才回来。并发上限和背压要一起设计并发上限不宜只设一个全局数字。模型服务、向量库、数据库和工具接口的承受方式不同可为各类依赖设置独立信号量和队列容量。请求到达超过容量时选择等待、快速失败、降级还是排入延迟队列取决于业务时效和幂等性。关键是把选择写清楚别让内存无限堆积后才用进程重启来“恢复服务”。取消也应成为正常路径。客户端断开、截止时间到达或上游失败时未开始的任务应停止排队正在等待的请求释放连接已经产生副作用的任务则记录状态供后续确认。吞掉取消异常会让后台工作悄悄继续无差别重试又可能把短暂拥堵放大成持续压力。只对明确可重试且无副作用的错误重试并设置有限次数与退避。不要只盯着一个漂亮指标提高吞吐可能增加排队时间降低平均延迟可能牺牲长请求减少模型调用也可能降低答案可用性。因此验证时同时观察成功率、超时、取消、资源使用和错误分布并保留失败样本。比较前固定数据集、请求组成、并发模型、资源配额和依赖版本没有这些条件任何“快了多少”的描述都不应被外推。调参以小步为宜。一次只改变一个限制或策略先在受控环境观察再决定是否扩大范围。若结果不符合预期先检查负载是否真的一致、缓存是否影响了结果、外部服务是否有波动。这样留下的不是一串神秘数字而是一条能复跑的判断过程。高并发系统最怕的不是慢而是不知道为什么慢、也不知道改完会伤到哪里。让后续维护有据可查前文已经分别谈到“先观察请求经过的几段路”“并发上限和背压要一起设计”和“不要只盯着一个漂亮指标”。把它们放在同一条链路里看才知道各自的前提有没有对齐。性能判断先回到请求实际经过的路径先用一个最小输入走完整流程记录入口参数、关键分支和最终产物。若某一步依赖默认值、环境变量或人工约定就把它写到调用点附近不要把判断藏在口头交接里。如果这部分会被交给同事维护验收不要只问“有没有完成”。更有用的问题是看着“并发上限和背压要一起设计”的结果能否判断输入是否被正确消费修改“不要只盯着一个漂亮指标”后能否找到受影响的地方撤掉这次改动时是否会留下半成品。答案不必承诺绝对安全但应当能对应到代码、配置或现有记录。收尾时建议把本次选择的限制也留下来。例如“先观察请求经过的几段路”暂时覆盖哪些情况哪些情况仍交给人工或旧路径“并发上限和背压要一起设计”依赖什么顺序或资源“不要只盯着一个漂亮指标”出现时用什么信号提醒。限制写出来并不削弱方案反而能避免后来的人把局部经验当成通用规则。没有上下文的单项指标很容易把排查带偏。本文的内容可以先从一个小场景开始使用碰到与假设不符的输入再把新发现补回规则而不是为了整齐把差异抹掉。