「优化了接口性能响应时间下降 60%」这句话几乎出现在每一份三年以上的后端简历里。它也几乎每次都会被追问。追问的方向很固定就三处。第一处优化前的基线是怎么测的问法是「60% 是从多少降到多少怎么测的」。答不上来的人通常是从监控面板上随手看的一个数。答得好的人会给出压测工具、并发数、数据量、统计口径平均值还是 P99。优化前500 并发下 P99 为 2.4s平均 800msJMeter 压测数据量 1200 万行 优化后同条件下 P99 为 600ms平均 210ms这四行写进简历会太长但你必须能说出来。简历上写结果脑子里存基线。第二处怎么定位到瓶颈的问法是「你怎么知道问题出在这里」。这一问考察的是方法不是结果。回答里应该出现具体手段火焰图、慢查询日志、链路追踪、GC 日志、还是打点统计。最怕的回答是「我觉得是数据库慢就加了缓存」。猜对了也是猜。简历上可以用一个短语带出方法通过链路追踪定位到 80% 耗时集中在一次 N1 查询上 改为批量查询 本地缓存P99 从 2.4s 降至 600ms「通过链路追踪定位到」这半句值整句话的一半。第三处代价是什么问法是「这么改有什么副作用」。任何优化都有代价加缓存带来一致性问题加索引拖慢写入异步化带来时序问题加机器带来成本。答「没有副作用」是最危险的回答它说明你没想过。能主动说出代价和你的处理方式这一轮基本就稳了代价是缓存与库存在最长 5s 的不一致窗口 对账场景走主库直读其余场景可接受没有大流量场景怎么办不是每个人都在做高并发系统。小流量场景下的优化同样可以写关键是把问题的真实性写出来。内部报表系统的月度导出从 12 分钟优化到 40 秒 原实现逐行查询关联数据约 3 万次单条查询 改为一次性预加载 内存关联 使用方是运营的 6 个人此前每月要在等待中损失约一小时。这段描述里没有百万 QPS但它完整问题真实存在、定位清楚、动作具体、影响的人是明确的。面试官不会因为规模小就否定它反而会因为你讲清楚了整个过程而加分。真正减分的是把小场景吹成大场景。一个可套用的四段式问题现象 → 定位手段 → 具体动作 → 结果与代价。四段压成一到两行写进简历剩下的细节留到面试里讲。顺带一条不要在简历上堆三条性能优化。挑最有代表性的一条写透比三条都写成「优化了某某提升了某某」有效得多。三个容易被问倒的追问一是「如果流量再涨十倍这个方案还成立吗」。考察的是你对方案边界的认知。答案里要有明确的瓶颈判断当前方案的下一个瓶颈在某某到那个量级需要改成某某。二是「有没有做过压测验证」。很多优化只在预发环境跑过一遍就上了。如实说明并给出你在线上是怎么观察的灰度比例、观察指标、回滚预案。三是「这个优化上线之后有没有引发别的问题」。有的话就说说清楚怎么发现、怎么解决的。这个回答的加分幅度往往比优化本身还大它证明你跟到了最后。最后一句性能优化在简历上是高频词也是最容易露怯的地方。一条写透胜过三条含糊。写之前问自己基线、定位、代价这三样我都说得出吗自查的办法是把每条描述读一遍问自己上面那三个问题能不能答。答不上来的要么补细节要么删掉。