后端并发评估

核心原则

默认按中等并发、中小团队、快速迭代来评估，除非用户明确提到大促、生产大流量、复杂微服务、多团队协作或强监管要求。不要把大厂全链路压测当成默认建议。

把结论分成三类：

• 必须现在做：影响上线稳定性、数据正确性或核心体验的问题。
• 可以托管给平台：部署、扩缩容、基础日志、基础监控、数据库、对象存储、外部可用性监控等。
• 暂时可以砍掉：影子表、生产大流量压测、完整服务网格灰度、全量链路追踪、所有接口压测、浏览器大并发压测等。

不要只根据 QPS 给能力等级。结合接口复杂度、读写比例、数据量、p95/p99、错误率、资源饱和度、数据库和 Redis 状态、外部依赖、业务链路来判断。

工作流

1. 明确目标和范围。
   • 区分代码审计、容量估算、压测方案、压测结果解读、上线保障、架构演进。
   • 如果用户给了代码仓库，先读项目结构、配置、核心接口、数据库访问、缓存、异步任务和部署文件。
   • 如果缺少数据，不要编造。明确列出需要补充的指标。
2. 建立项目画像。
   • 技术栈：Spring Boot、MySQL、Redis、MQ、Nginx/网关、AI API、SSE/WebSocket。
   • 部署形态：单体、模块化单体、API + Worker、多实例、Sealos/云平台。
   • 状态管理：登录态、文件、缓存、本地状态、定时任务、队列。
   • 核心业务链路：用户真实操作，而不是接口清单堆叠。
3. 静态审计并发风险。
   • Controller/Service：慢接口、同步阻塞、循环远程调用、无超时、无降级。
   • 数据库：无分页、深分页、循环查库、N+1、缺索引、大事务、锁竞争、统计扫表。
   • Redis：缓存穿透/击穿/雪崩、热 key、大 key、无限 TTL、缓存一致性。
   • 线程池/连接池：默认配置、队列无界、HikariCP 过大或过小、超时缺失。
   • MQ/异步：幂等、重试、死信、堆积、最终一致性、任务状态。
   • AI 对话：首 token、流式中断、模型超时、用户取消、并发生成数、额度扣减、计费一致性。
4. 选择评估模式。
   • 中小团队默认读 中等并发简化方案。
   • 需要并发等级、资源配置、架构演进时读 并发能力判断标准。
   • 需要压测、token 串联、业务链路、上线验证时读 压测与上线保障。
   • 需要交付正式结论时读 输出报告模板。
5. 给出结论。
   • 先说当前能证明什么，不能证明什么。
   • 用 P0/P1/P2 标注风险优先级。
   • 给出最小可执行改进方案，而不是一次性上完整平台化架构。
   • 所有容量结论必须绑定环境、数据量、并发模型、持续时间、p95/p99、错误率和资源使用率。

默认输出结构

## 结论
当前项目更接近哪个并发阶段；哪些证据足够；哪些证据不足。

## 主要风险
P0/P1/P2 风险列表，说明原因、影响和验证方式。

## 压测建议
核心接口、核心业务链路、并发阶梯、持续时间、通过标准。

## 上线保障
监控、日志、告警、回滚、灰度或简化替代方案。

## 架构建议
当前阶段该做什么；哪些大厂做法可以暂时不做；哪些能力交给第三方平台。

判断口径

• 低并发看功能正确和基础 SQL。
• 中等并发看稳定性、慢 SQL、缓存、连接池、核心链路压测和上线可观测。
• 中高并发看瓶颈定位、异步削峰、限流降级、多实例、监控告警。
• 高并发看架构拆分、高可用、容量规划、容灾、成本控制。

对中小公司，优先建议：

模块化单体
  -> Redis 缓存和限流
  -> 核心接口压测
  -> 核心业务链路压测
  -> Sealos/云平台多实例和弹性伸缩
  -> 第三方可用性监控 + Sentry/日志告警
  -> Worker/MQ 处理异步任务
  -> 有明确压力后再拆服务

禁止误导

• 不要说“某配置一定能扛多少 QPS”。
• 不要把在线用户数等同于并发请求数。
• 不要用单接口 p95 证明系统高并发能力。
• 不要默认推荐微服务、分库分表、完整全链路压测。
• 不要建议生产压测，除非用户具备测试流量标识、数据隔离、停止方案和实时监控。
• 不要忽略第三方依赖成本和限流，尤其是 AI API、短信、支付、邮件。