刚接手公司CRM系统升级项目时，销售总监拍着桌子说：‘新方案必须扛住双十一级别并发！’——结果上线后发现，登录慢、报表卡、批量导出直接超时。后来查了一圈，问题不在服务器配置，而在几个关键接口没做连接池复用，数据库查询还带着N+1漏洞。
性能不是跑分，是真实场景里的呼吸感
很多厂商PPT里写的“支持10万并发”，实际可能只测了单个登录接口空载压测。企业用的不是接口，是人：财务在月底关账时批量审核单据，HR在发薪日前集中导出考勤数据，客服坐席同时打开客户历史订单+服务记录+合同扫描件——这些组合操作才是真正的压力源。
盯紧这三块骨头
响应时间不是平均值：看P95或P99延迟。比如一个订单提交接口，平均耗时200ms，但1%的请求要3秒以上，那这1%很可能就是用户反复刷新、最终放弃下单的那批人。
资源利用率要能‘喘气’：CPU长期跑95%，就像让汽车发动机始终在红线区转速。某次我们把Java应用堆内存从8G调到4G，反而减少了GC停顿，整体吞吐量还升了12%——因为系统终于有余力处理突发IO等待了。
扩容不能只加机器：曾有个客户把ERP系统从1台服务器扩到4台，性能却更差了。查下来是所有节点共用同一个Redis实例，缓存穿透+锁竞争全挤在一处。后来拆成读写分离+本地缓存二级架构，同样4台机器，TPS翻了两倍。
自己动手摸一摸性能底细
不用等厂商报告，登录服务器敲几行命令就能看出门道：
top -b -n 1 | grep 'java' # 看Java进程实际占用CPU和内存
curl -s http://localhost:8080/actuator/metrics | jq '.names[] | select(contains("http"))' # Spring Boot项目查HTTP请求指标
mysql -e "SHOW PROCESSLIST;" | wc -l # MySQL当前活跃连接数真正稳的企业级系统，性能表现往往藏在细节里：数据库连接是否复用、日志是否异步写入、前端静态资源有没有CDN加速、API网关是否做了请求合并……这些不 flashy 的设计，才是业务连续性的底气。