性能提升 - 怎样记录变更与复盘：用证据链定位原因
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /826d4554f226.html
📄
性能提升 - 怎样记录变更与复盘：用证据链定位原因
性能提升过程中记录变更与复盘，核心做法是：每次只改一个变量，改动前后各留一组可对比的数据，并把时间、环境、改动内容、观察结果写进同一份记录。这样出问题时能回答“哪次改动导致了什么现象”，而不是凭印象猜测。适用前提是你能控制改动节奏、能重复测量同一指标；如果多个改动同时上线，复盘只能得到相关性，无法定位唯一原因。
先建立一份最小可用的变更记录
记录不需要复杂工具，一张表或一个文本文件即可，但字段要固定。建议包含以下内容：
- 时间：改动的具体时间点，精确到分钟，便于和监控曲线对齐。
- 改动内容：改了哪个文件、哪个配置、哪段代码，写清具体值的前后对比。
- 变更类型：属于代码、缓存策略、资源加载、数据库查询还是服务器配置。
- 预期影响：你希望它改善哪个指标，比如首屏时间、接口响应时间。
- 观测数据：改动前后的指标值，注明测量工具和测量条件。
- 结论：保留、回滚还是继续观察。
关键点是“预期影响”这一栏。没有预期，事后就无法判断改动是有效、无效还是有害。例如你压缩了一张图片，预期是减少传输体积，那就记录压缩前后的字节数，而不是笼统写“优化了图片”。
测量环节要固定条件，否则数据不可比
性能数据受网络、设备、缓存状态、并发量影响很大。要让前后数据可比，至少固定三点：同一测量工具、同一测量位置、同一测试条件。比如都用同一台机器、同一浏览器、清空缓存后测三次取中位数。如果条件变了，要在记录里注明，不能直接和上一次的数字比较。
判断结果时区分两种信号：
- 方向一致的信号：多次测量都朝同一方向变化，且幅度超过测量本身的波动范围，可以认为改动有效。
- 方向不一致的信号：一次变快一次变慢，说明波动大于改动效果，需要增加测量次数或换更稳定的指标。
适用条件是你能重复触发同一操作。如果页面依赖实时数据、每次内容都不同，就先固定一份测试数据再测。
复盘时按“现象—证据—结论”推进
复盘不是重述做了什么，而是回答三个问题：现象是什么、证据指向哪里、下一步怎么办。
- 描述现象：写清哪个指标、在什么条件下、从多少变成多少。例如“列表页首屏渲染从 1.8 秒变为 2.6 秒，测试条件相同”。
- 列出候选原因：把可能解释这一现象的原因都写出来，比如新增了同步请求、缓存未命中、资源体积变大。此时不要急着下结论。
- 用证据排除：逐个核对。查看网络面板确认请求数量是否增加，查看缓存命中记录确认是否命中，查看文件体积确认是否变大。能排除的划掉，剩下的才是已定位的原因。
- 给出动作：回滚、修正还是保留观察，并写明下次验证的方式。
这里要区分“可能原因”和“已经定位的原因”。现象是响应变慢，可能原因有多个；只有当你拿到具体证据，比如确认某次改动新增了一个阻塞请求，才能写成已定位的原因。
一个可执行的短例子
假设你怀疑某次改动拖慢了页面（以下为假设示例，不是真实项目结果）。
记录写法：改动前首屏 1.5 秒，改动后 2.2 秒；改动内容为在页面头部新增一段脚本；测量条件为同一设备清空缓存测三次取中位数。
复盘写法：现象是首屏变慢约 0.7 秒；候选原因包括新增脚本阻塞渲染、资源竞争、缓存失效；核对证据时发现该脚本为同步加载且体积较大，移除后首屏回到 1.5 秒附近，因此定位为同步脚本阻塞渲染；动作为改为异步加载或延后加载，并重新测量确认。
这个例子的验收信号是：改动回退后指标回到原水平，再次应用修正方案后指标不低于原水平。如果回退后指标没有恢复，说明还有别的原因，需要继续排查。
把记录变成可复用的检查清单
每次改动前问自己四个问题：这次改了什么、预期影响哪个指标、怎么测、测完和谁比。每次复盘后补一句：下次遇到同类改动，应该先看哪个证据。坚持几轮之后，你会得到一份属于自己的排查顺序，而不是每次从零开始猜。
下一步：为当前正在做的性能改动建一份记录表，填入最近一次改动的前后数据和测量条件，然后按上面的复盘步骤写出候选原因与已定位原因，再决定保留还是回滚。
