拿了一个全省第三的奖牌技术负责人反而失眠这不算矫情。分数公布后差距被压缩到了个位数性能测试低了两分稳定性场景丢了三分答辩材料里缺少压测报告和回滚方案又被扣了两分。回头翻代码这些问题都有明确出处不是做不出来而是没有在交付前用工程手段把它们拦截下来。“一个全省第三的遗憾”翻译成技术语言就是一次系统性的赛后复盘名次只是结果真正要处理的是结果背后的技术差距。这篇文章围绕一个非常常见的复盘场景展开项目在省级评选中拿到第三名但复盘后发现失分点集中在性能、稳定性、代码质量和交付物四个方面。文章会用一套示例的在线报名系统走通完整复盘过程覆盖压测方法、瓶颈定位、超时与熔断配置、静态检查与单元测试、发布回滚和复盘清单。读完可以直接把同一套分析思路迁移到自己的项目里即使不是比赛项目也能用于生产系统的性能排查和发布前检查。1. 遗憾不是名次问题而是评分维度里的技术差距团队或个人的第三名遗憾往往不是“再做多一点就能第一”的模糊感觉而是评分表上几项可量化的差距。复盘的第一步不是写一篇感性的总结而是把失分点从评分语言翻译成工程语言再定位到代码、配置、流程和交付物上。1.1 先搞清楚评审在评什么在省级技能竞赛、软件设计评选、项目答辩这类场景中评分一般不会只看“功能能不能跑”。综合多个技术类评审中常见的评分口径大致可以分成这样几类评分维度常见评审关注点对应工程证据功能完整性需求覆盖度、核心流程是否跑通、边界处理是否合理需求清单、接口测试用例、功能演示截图或视频性能表现并发能力、响应时间、资源占用压测报告、QPS、TP99、错误率、CPU/内存曲线稳定性异常输入、依赖故障、极端流量下系统是否可用异常处理代码、超时与熔断配置、故障演练记录代码质量可读性、可维护性、是否存在明显坏味道静态检查报告、单元测试、覆盖率报告交付物部署是否顺畅、文档是否完整、团队能否快速接手README、部署文档、环境说明、日志规范现场答辩讲解是否清楚、问题是否能接住架构图、设计文档、复盘记录这套评分逻辑和真实生产项目的验收逻辑高度一致。评审不会一台机器一台机器检查代码是否漂亮但会看有没有证据而证据是否严谨直接反映了开发团队是否具备工程化交付能力。1.2 把失分项映射到工程证据拿到评分反馈后常见的错误做法是把失分原因写成人人会写的结论比如“性能优化不够”“代码质量需要提升”“文档偏少”。这些话没有任何执行价值。正确的做法是先建立一张映射表把每个失分项对应到具体文件和可以验证的动作。例如评分反馈可能的技术根因需要检查的证据并发场景下响应慢慢 SQL、N1 查询、缓存配置缺失慢查询日志、压测火焰图、SQL 执行计划接口偶发 500连接池耗尽、外部接口超时未处理日志中的连接超时关键字、线程栈、监控图表故障恢复能力不足没有回滚方案、没有健康检查发布脚本、actuator/health 配置、回滚演练记录代码阅读困难包结构混乱、命名不统一、缺少分层代码目录、静态检查告警列表文档不够README 只有启动命令缺少架构和部署说明文档目录、部署脚本、接口说明完成映射之后遗憾就被拆成了一个个可以修复的具体问题。1.3 复盘使用的示例系统为了让后面的分析可以落地这篇文章使用一个示例项目“在线活动报名系统”来说明复盘过程。技术栈为 Spring Boot 3、Spring Data JPA、MySQL 8、Redis 7压测工具使用 k6。系统包含活动查询、报名接口、报名人数统计、报名记录列表、短信通知触发五个模块。这里要说明一点示例项目用于展现复盘思路不指代任何真实赛事或真实作品。如果你手头项目使用的不是 Spring Boot 或 JPA分析思路依然适用只需把工具和配置替换成自己技术栈里对应的一层。2. 第一类遗憾性能差距没有被量化性能失分在整个遗憾里占比通常不低。更可惜的是很多性能问题在评审前就存在只是团队没有通过压测提前发现。没有压测基线优化就无从谈起因为“快”和“慢”没有数据支撑。2.1 没有压测基线优化就无从谈起复现评审场景的第一步是准备一个与预期访问量匹配的压测环境。对于在线报名系统模拟的高峰场景是活动开放报名后数千人同时进入页面、提交报名、查询剩余名额。这里使用 k6 编写一段简单的阶梯加压脚本。阶梯加压的目的是先观察低并发下是否正常再逐步增加并发找到系统从正常到劣化的拐点。import http from k6/http; import { check, sleep } from k6; export const options { scenarios: { load: { executor: ramping-vus, startVUs: 0, stages: [ { duration: 30s, target: 50 }, { duration: 1m, target: 200 }, { duration: 30s, target: 0 }, ], }, }, }; export default function () { const payload JSON.stringify({ eventId: 1001, userId: __VU, name: 用户 __VU, phone: 1380000 (1000 __VU), email: user __VU example.com, }); const params { headers: { Content-Type: application/json }, }; const res http.post(http://localhost:8080/api/registration, payload, params); check(res, { status is 200: (r) r.status 200, response time 500ms: (r) r.timings.duration 500, }); sleep(1); }运行压测命令k6 run load-test.js运行前要确认测试数据足够接近真实场景不能只有十几条数据。至少准备几十万条历史报名记录和几千个活动否则数据库索引、缓存和磁盘读取都无法真实暴露。2.2 读压测报告QPS、错误率、TP99 分别代表什么k6 结束时会输出一组汇总指标。最关键的是下面几个指标含义判读思路http_reqs总请求数结合时间估算每秒请求数与预期峰值对比判断是否达标http_req_duration平均响应时间看均值但不能只看均值http_req_duration{...} 的 p(95) / p(99)95% 和 99% 请求的响应时间TP99 更能反映极端用户感受http_req_failed失败请求比例正常压测应趋近于 0出现非 0 时需要定位iterations完成的主流程次数判断业务处理能力例如压测输出中出现 p(99) 超过 2000ms、http_req_failed 大于 2%基本可以判断系统在 200 并发附近已经不健康。2.3 从压测里发现的典型性能问题懒加载导致 N1一个非常典型的性能瓶颈是 JPA 懒加载导致的 N1 查询。报名记录列表接口的逻辑是先查出某个活动下的所有报名记录再循环读取每条记录对应的用户名称。第一次查询报名表走一条 SQL循环读取 100 条用户信息时又产生 100 条 SQL数据库压力瞬间放大。最初的 Repositorypublic interface RegistrationRepository extends JpaRepositoryRegistration, Long { ListRegistration findByEventId(Long eventId); }Service 中的循环读取ListRegistration list registrationRepository.findByEventId(eventId); ListRegistrationVO result new ArrayList(); for (Registration reg : list) { // 这里触发懒加载每行记录查询一次 user 表 String userName reg.getUser().getName(); result.add(new RegistrationVO(reg.getId(), reg.getEventId(), userName, reg.getCreatedAt())); }修复方式是让查询一次性把关联对象查出来。使用EntityGraph指定需要一起加载的属性public interface RegistrationRepository extends JpaRepositoryRegistration, Long { EntityGraph(attributePaths {user}) Query(select r from Registration r where r.eventId :eventId) ListRegistration findByEventIdWithUser(Param(eventId) Long eventId); }修改后Service 只需调用findByEventIdWithUser数据库从 101 条 SQL 变成 1 条接口响应时间通常能下降一个数量级。2.4 缓存计数的正确姿势防穿透、防击穿报名人数的实时统计也是性能高发点。如果每次都执行count(*)高并发下会把数据库打满。常见的优化方式是引入 Redis 缓存但缓存并不总是安全的。先看一个“看起来正确”的缓存代码public long getRegisteredCount(Long eventId) { String key event:registration:count: eventId; String cached stringRedisTemplate.opsForValue().get(key); if (cached ! null) { return Long.parseLong(cached); } long count registrationRepository.countByEventId(eventId); stringRedisTemplate.opsForValue().set(key, String.valueOf(count), Duration.ofMinutes(5)); return count; }这段代码有两个隐患缓存穿透和缓存击穿。如果某个不存在的eventId被反复查询每次都会打到数据库如果缓存刚过期大量请求同时回源数据库数据库瞬间被压垮。针对当前场景可以用互斥锁避免击穿同时借助空值缓存应对穿透public long getRegisteredCountSafe(Long eventId) { String key event:registration:count: eventId; String value stringRedisTemplate.opsForValue().get(key); if (value ! null) { return Long.parseLong(value); } String lockKey lock: key; Boolean locked stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(5)); if (Boolean.TRUE.equals(locked)) { try { value stringRedisTemplate.opsForValue().get(key); if (value ! null) { return Long.parseLong(value); } long count registrationRepository.countByEventId(eventId); stringRedisTemplate.opsForValue().set(key, String.valueOf(count), Duration.ofMinutes(5)); return count; } finally { stringRedisTemplate.delete(lockKey); } } else { // 拿不到锁的请求先回查数据库保证功能可用 return registrationRepository.countByEventId(eventId); } }这段代码不复杂但它体现了生产环境里“缓存要兜底不能放大故障”的思路。2.5 压测后的复测要求性能优化是否有效不能靠“感觉变快了”来判断必须用同一套压测脚本、同一份测试数据、同一台压测机复测。复测后要形成一张对比表指标优化前优化后差异200 并发下 QPS120480提升 300%平均响应时间420ms110ms下降 73%TP991900ms480ms下降 75%错误率3.2%0%恢复正常评审看到这样的表格比看到“我们优化了性能”这句话有说服力得多。团队自己也获得了可以持续迭代的基线数据。3. 第二类遗憾稳定性在极端场景下露馅性能之外稳定性是另一个容易丢分的环节。很多系统在演示环境里一切正常但评审会故意问“如果这个接口突然变慢怎么办”“如果 Redis 挂了怎么办”“发布后发现问题怎么回滚”这些问题答不上来基本就是稳定性失分。3.1 连接池超时偶发 500 的排查链路一个很常见的现象是系统平时正常并发一高就偶发 500错误日志里出现类似下面的内容HikariPool-1 - Connection is not available, request timed out after 3000ms这段日志的意思是应用向数据库连接池请求连接时等待超过了 3000ms。连接池里所有连接都被占用了新的请求只能等待。排查顺序如下确认是不是连接池配置过小。查看spring.datasource.hikari.maximum-pool-size的当前值。确认是不是存在慢 SQL 占住连接。开启 MySQL 慢查询日志SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;检查是不是存在事务内调用外部接口的情况。事务未提交时连接一直不释放。通过线程转储观察线程状态。可以用jstack导出线程栈看线程阻塞在哪里。如果确认是连接池配置问题可以调整 Hikari 参数spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 3000 validation-timeout: 1000 max-lifetime: 1800000参数含义如下参数作用设置建议maximum-pool-size连接池最大连接数不宜过大默认 10 在多数场景不够建议从 20 开始压测观察minimum-idle空闲连接数与最大连接数拉开差距避免空闲连接占用资源connection-timeout获取连接的最大等待时间建议 2000-3000ms超过即快速失败max-lifetime连接最大存活时间小于数据库 wait_timeout默认 1800000ms 通常可用连接池不是越大越好。如果数据库连接数上限是 100应用实例有 5 个每个配 50 就会直接打满数据库。要先确认数据库max_connections再做压力测试验证。3.2 外部依赖不可用时系统要能降级在线报名系统需要调用短信服务发送通知。在高并发或第三方服务不稳定时如果短信接口超时且没有兜底用户提交报名会一直卡住甚至拖垮整个应用。稳定的做法是对外部调用设置超时、重试和熔断。以 Resilience4j 为例配置一段短信通知的熔断策略resilience4j: circuitbreaker: instances: smsNotify: slidingWindowSize: 20 minimumNumberOfCalls: 5 permittedNumberOfCallsInHalfOpenState: 3 automaticTransitionFromOpenToHalfOpenEnabled: true waitDurationInOpenState: 10s failureRateThreshold: 50 recordExceptions: - java.io.IOException timelimiter: instances: smsNotify: timeoutDuration: 2s cancelRunningFuture: true策略含义是在 20 次调用中如果有 50% 失败熔断器打开 10 秒期间直接返回失败或走降级逻辑不再继续打爆短信服务。这样既保护了外部服务也保护了自身线程池。在业务代码里短信通知不应该阻塞报名主流程。推荐做法是把通知放入消息队列或者至少使用 Spring 的Async异步执行并配合降级记录Async(smsExecutor) public void sendNotificationAsync(Registration reg) { try { smsClient.send(reg.getPhone(), buildMessage(reg)); } catch (Exception e) { log.warn(send sms failed, registrationId{}, phone{}, reg.getId(), reg.getPhone(), e); // 写入失败列表后续通过补偿任务重试 } }面试或答辩中能说清楚“短信失败不会影响报名成功”这一类设计比背诵多个框架名词更能证明稳定性意识。3.3 发布后的回滚能力是评审中的隐性失分点很多项目在评审前一刻做了最后一次“小改动”结果破坏了核心流程。这类事故的本质是发布过程没有留后路。生产环境的发布至少要有三件套备份、健康检查、回滚方案。一种最基础的回滚流程是# 1. 备份当前版本 cp /opt/app/app.jar /opt/app/backup/app.jar.$(date %Y%m%d%H%M%S) # 2. 替换新版本 cp /tmp/new-app.jar /opt/app/app.jar # 3. 重启服务 systemctl restart registration-service # 4. 健康检查连续 30 次每 2 秒一次 for i in $(seq 1 30); do if curl -fsS http://localhost:8080/actuator/health; then echo health check ok exit 0 fi sleep 2 done # 5. 检查失败则回滚 cp /opt/app/backup/app.jar.$(date %Y%m%d%H%M%S) /opt/app/app.jar systemctl restart registration-service echo rolled back健康检查接口要配置在 Spring Boot 的 actuator 里management: endpoints: web: exposure: include: health,info,metrics,prometheus评审时如果能现场演示“发布失败后自动回滚”稳定性这一项的得分通常会明显好于只在 PPT 里写“我们支持回滚”的项目。4. 第三类遗憾代码质量和交付物没有形成证据第三名遗憾里还有一类失分不是因为功能弱而是因为代码质量、测试和交付文档没有形成证据。评审或接手团队看不到你的质量保障体系自然不敢给出高分。4.1 评审关心的代码质量不是“看起来很规范”单纯把类名写得规范、Controller 不分层并不能证明代码质量。评审更关心的是你是否用工具强制约束了代码质量是否在提交前跑过自动化检查是否还有可复现的质量报告。常用的证据包括静态检查报告SpotBugs、Checkstyle、ESLint 等产生的报告。单元测试报告JUnit 等产生的测试执行结果。覆盖率报告JaCoCo 等产生的行覆盖率和分支覆盖率。代码评审记录Merge Request 或 Pull Request 的评审记录。4.2 用 SpotBugs 和 JaCoCo 把质量门槛自动化以 Maven 项目为例可以在pom.xml中同时配置 SpotBugs 和 JaCoCo让质量检查成为mvn verify的一部分。SpotBugs 配置plugin groupIdcom.github.spotbugs/groupId artifactIdspotbugs-maven-plugin/artifactId version4.8.6.0/version configuration effortMax/effort thresholdLow/threshold failOnErrortrue/failOnError /configuration /pluginJaCoCo 配置plugin groupIdorg.jacoco/groupId artifactIdjacoco-maven-plugin/artifactId version0.8.12/version configuration excludes exclude**/dto/**/exclude exclude**/entity/**/exclude /excludes /configuration executions execution goals goalprepare-agent/goal /goals /execution execution idreport/id phasetest/phase goals goalreport/goal /goals /execution execution idcheck/id phaseverify/phase goals goalcheck/goal /goals configuration rules rule elementBUNDLE/element limits limit counterLINE/counter valueCOVEREDRATIO/value minimum0.70/minimum /limit /limits /rule /rules /configuration /execution /executions /plugin配置完成后运行mvn clean verify如果测试覆盖率低于 70%构建会失败。评审时直接把target/site/jacoco/index.html的报告截图放进答辩材料代码质量就不再是空话。4.3 日志、README、部署文档是评审最容易翻看的部分评审或下一个维护者最先打开的文件通常是 README 和日志。如果 README 里只有“如何启动”没有架构说明、配置说明、接口说明和部署方式交付物得分就会被拉低。一份合格 README 至少包含章节内容项目简介解决什么问题核心模块有哪些技术栈语言、框架、数据库、缓存、中间件版本快速启动环境要求、依赖服务、启动命令、默认端口配置说明关键配置项、环境变量、配置文件位置接口文档主要接口、请求响应示例、错误码部署说明打包方式、部署目录、健康检查、回滚方法常见问题端口冲突、数据库连接失败、缓存连接失败等日志方面推荐使用结构化日志。JSON 格式的日志便于采集到日志平台也便于按字段检索appender nameJSON classch.qos.logback.core.ConsoleAppender encoder classnet.logstash.logback.encoder.LogstashEncoder customFields{app:registration-service,env:dev}/customFields /encoder /appender日志中要保留 traceId便于串联一次请求的完整链路。在网关或过滤器初始化 traceId并使用 MDC 传递排查问题时效率会高很多。5. 通用复盘模板把“遗憾”变成下一轮迭代清单复盘不能只停留在口头分析最后一定要落到清单和计划。没有输出物的复盘几天后就会被遗忘下一次项目又会出现同样的遗憾。5.1 一套可复用的项目复盘清单下面这份清单可以直接复制到团队文档中填完即为本次复盘的交付物复盘项证据来源技术根因改进行动验证方式责任人是否完成性能不达标k6 压测报告懒加载 N1使用 EntityGraph 批量加载复测 TP99 下降张三是偶发 500错误日志连接池耗尽调整 Hikari 参数压测 300 并发无 500李四是短信接口拖慢报名线上监控外部调用无超时熔断配置 Resilience4j模拟短信超时验证降级王五是发布无回滚部署文档缺失缺少健康检查和备份补充发布脚本演练一次失败回滚赵六是代码质量无证据SpotBugs/Jacoco 报告未接入自动化检查配置 Maven 插件CI 中执行 verify张三是每一条都必须能回答“怎么证明修好了”而不是“应该修好了”。5.2 三个月的改进节奏建议复盘结束后建议把改进项排进正常的迭代计划而不是攒到评审前集中补。一个可执行的三阶段节奏如下第 1 个月建立基线。先解决性能问题、连接池问题、缓存穿透击穿问题形成第一份压测报告和稳定性报告。第 2 个月加固稳定性。配置超时与熔断补充发布回滚脚本进行一次故障演练。第 3 个月形成质量门槛。接入静态检查、单元测试覆盖率检查、结构化日志更新 README 和部署文档。三个阶段完成后再跑一次同样的压测场景基本能拿到一份比之前好看很多的对比数据。5.3 每次交付前要过的“防遗憾检查”把复盘结论提炼成一份发布前检查清单每次交付前逐项确认是否跑过压测并记录 QPS、TP99、错误率是否检查过慢 SQL 和 N1 查询是否设置了数据库连接池、外部接口超时和熔断是否验证过 Redis 不可用时的降级逻辑是否做过一次发布回滚演练是否执行了静态检查和单元测试覆盖率检查是否更新了 README、部署文档、接口文档是否在日志中保留了 traceId方便线上排查这份清单不需要复杂工具哪怕放在团队文档里也能减少重复踩坑。6. 最后一件事让遗憾成为团队改进指令“一个全省第三的遗憾”之所以有复盘价值是因为它证明了团队已经具备完成任务的能力差的只是工程化兜底。性能有没有量化基线连接池超时有没有处理外部依赖挂了能不能降级发布失败能不能回滚代码质量有没有自动化证据这些点不会决定一个项目从无到有但会决定它在高强度评审、高并发场景和突发故障面前能走多远。下一次再做类似项目时不要等到结果出来再复盘。从演示环境、压测到发布流程都应该按这篇博客里的检查清单提前跑一遍。把遗憾留在这一次复盘里把改进动作带进下一个迭代版本第三名才会真正成为一个转折点而不是一句口头上的可惜。