后端并发服务的适用边界与反例并发提高等待外部资源时的利用率却不能消除计算瓶颈、锁竞争和下游限速。分清任务类型网络请求适合异步等待计算密集任务要设并发上限。共享状态无法避免时应明确所有权和串行位置。并发模型要从任务的主要等待点出发。网络、磁盘和数据库调用常常需要等待外部资源有限的并发可以提高资源利用率压缩、加密、图像处理和模型推理更容易受 CPU、GPU 或内存带宽限制盲目增加 worker 反而增加上下文切换与排队。先用压测和运行时指标确认瓶颈再决定是否拆分队列、增加实例或优化算法。共享状态是并发设计中最容易被忽略的成本。缓存、连接池、限流器和订单状态都可能在高并发下产生锁竞争或顺序问题。优先缩小共享范围、使用不可变数据或明确的消息所有权确实需要串行的操作就显式串行不要让多个任务在隐蔽的全局变量上互相等待。对外部写入使用幂等键和业务状态避免重试造成重复副作用。检查取消与背压模拟下游变慢、客户端断开和队列积压确认任务停止后资源能释放且调用方得到合适错误。取消信号必须沿调用链传递。客户端离开后HTTP 请求、数据库查询、模型调用和后台任务若仍继续消耗资源系统在高峰期会积累大量无用工作。测试超时和取消时检查连接是否关闭、锁是否释放、队列任务是否标记为可重试或已放弃并避免在日志中重复打印同一错误。背压不是只设置一个队列长度。队列接近上限时系统要决定是拒绝新请求、降低优先级、返回稍后重试还是把工作转移到异步通道。这个决定应与业务风险一致可延迟的通知可以等待高价值写操作需要稳定的接收确认。调用方收到的错误应可识别不能把容量不足伪装成成功。维护并发前提设计记录应写明超时来源、拒绝策略和上限依据输入规模变化后再评估不要机械增加线程。并发上限应根据实例资源、下游容量、请求形状和恢复目标设置并在负载变化后重新测量。监控至少包含活动任务数、等待时间、队列长度、超时、拒绝和资源使用只看平均 CPU 或平均延迟会掩盖尾部拥塞。告警触发后先确认是否是下游变慢、依赖限速还是本地泄漏再调整策略。运行手册写清如何暂停消费、如何缩小并发、如何清理积压和何时升级事件。把这些前提和测试场景保留在设计记录中新成员才能理解为什么某个上限存在。并发的价值是让服务在等待中保持响应而不是用更多线程把不可承受的工作更快地推向下游。