页面转圈五秒，用户已经关了。

上一篇我们把代码”擦干净”了，但没让它变快一分一毫。

这一篇要处理的，是所有人都会遇到的另一个难题：代码不光要好读，还得跑得动。 而这两件事经常打架——你会发现一个残酷规律：让代码变快的手段，多半会让它变难懂。 加缓存、批量、并发，每样都在往代码里塞额外复杂度。

所以”优化”和重构完全不同：

重构是”只赚不赔”，优化是”有得有失”。

重构改完更好懂、功能没变、没有代价。优化改完更快了，但总要付出点什么——可读性、内存、或多一个可能出错的环节。既然是买卖，就得先算账。

一、优化三问：值、位、价

动手之前先问自己三句话，口诀“值、位、价”。

第一问：值不值得改？（值）

这一问能砍掉八成无效优化。问自己：现在这个速度，真的有人在抱怨吗？

• 后台页面加载 1.2 秒 —— 不用改，没人骂你。
• 点提交转圈 6 秒 —— 必须改，已经在流失用户。
• 一年跑一次的报表脚本跑 10 分钟 —— 不用改，花两小时优化一年只省 9 分钟。

很土但好用的尺子：

过早优化是新手最大的时间黑洞。 你花一下午把 0.3 秒优化到 0.2 秒，用户完全无感，代码却多了一层没人懂的逻辑。

第二问：改哪一处？（位）

回到第 73 篇铁律：先测量，再优化。 绝大多数程序耗时符合规律：80% 的时间花在 20% 的代码上。 你随手挑一段优化，大概率优化了一段本来就不慢的东西。

顺序永远是：先测（整个流程几秒）→ 再拆（几秒分别花在哪）→ 锁定（占比最大的那段）→ 只改它，其他不动。没有测量数据就优化，等于蒙眼开枪。

第三问：代价是什么？（价）

最容易被跳过、也最要命的一问。任何优化都有代价，常见四种：

• 可读性（代码变绕）
• 内存（用空间换时间，缓存多了爆内存）
• 一致性（加了缓存数据可能旧）
• 复杂度（多一个可能出错的环节）

让 AI 优化时，一定要逼它把代价说出来。 它默认只吹”性能提升 80%”，不会主动告诉你”但数据可能延迟 5 分钟”。

二、提速四招：少、缓、批、延

真要改的时候，小白只需认识四类手段，口诀“少、缓、批、延”。这四招覆盖日常九成性能问题。

第一招：少（少做点事） 最朴素也最有效：本来做十次改做一次。比如计算结果在循环里被反复算一千遍，算一遍存起来就行；从数据库查一万条回来在代码里筛五条——为什么不让数据库直接给那五条？代价：几乎没有，永远优先用。

第二招：缓（算过的存起来） 同样问题第二次直接给上次答案。城市列表、商品分类、汇率一天不变，每次查库纯浪费。代价：数据可能是旧的。 用缓存前先问：”这个数据过期 5 分钟会出事吗？”城市列表没事，账户余额过期 5 分钟出大事。

第三招：批（一次一批，别一次一条） 数据库操作上效果最猛，常快十倍以上。要存 1000 条却循环一条条存 1000 次，光”打招呼”就耗掉大部分时间，打包一次送过去直接起飞。代价：一批里一条出错，整批怎么办？要提前想清。

第四招：延（不急的放后面） 用户等的马上做，不急的挪后面。点”提交订单”依次做了存订单→扣库存→发短信→发邮件→写日志——用户等的只是”存没存上”，后面三件他不在乎。挪后台慢慢做，等待时间砍掉一大半。代价：多一个”后台那步失败了怎么办”的问题。

三、性能和可读性打架时，听谁的？

先给结论：99% 情况下，可读性优先。 依据很硬：你 99% 的代码根本不在瓶颈上，那部分写得再”高效”对整体速度影响近零，但变难懂的代价你每天承受。

真要为速度牺牲可读性，你有义务留三样东西，否则三个月后这段代码成没人敢碰的雷区：

1. 一段”为什么”注释——不要写”这里做了缓存”（代码看得出），要写清背景：哪天排查发现首页每次查全量分类表、单次 800ms、占首页 70%、分类日均变 0-1 次、允许 10 分钟延迟。
2. 一组数字——”优化前 6.2 秒，优化后 1.1 秒”，写进注释，是后人判断”这段还值不值得留”的唯一依据。
3. 一句”什么情况可删掉”——比如”分类降到 50 条内，这缓存可直接删”。

没有这三样，你留的不是优化，是定时炸弹。

四、实战：完整的一次优化对话

场景：用户点”导出订单”，转圈 12 秒。

第一步：先量（别跳过）。 第一句话不该是”帮我优化”，而是”帮我测量”。让 AI 加计时点跑一次，看 12 秒花在哪：

查询订单数据      1.1 秒
循环处理每条订单  9.8 秒   ← 元凶
生成文件          0.7 秒
写入响应          0.4 秒

优化的目标只有一个——那 9.8 秒。 剩下三段加起来才 2.2 秒，优化到 0 也只省两秒。

第二步：让 AI 给方案，但要它列代价。 关键：不要直接要代码，先要方案对比表。

选择很明显：方案 A——效果最好、代价最低、风险最小，用的正是”批”。循环里查库是新手最常见性能杀手，行话叫 N+1 查询。方案 B 那种”加多线程”听着高级，但并发引入的 Bug 比它解决的性能问题更麻烦，能不用就不用。

第三步：只改这一处，改完再量。 从 12 秒降到 3.7 秒。这时停下问第一问：”还值得继续改吗？”3.7 秒已从”以为坏了”变成”有点慢但能接受”，再抠收益递减、风险递增。优化最容易上瘾，见好就收是一种能力。

五、三个新手最容易踩的优化陷阱

陷阱一：相信 AI 报的”提升百分比”。 它很自信说”提升 80%”，那是它猜的——没跑过你代码、不知数据量、不知配置。唯一可信的数字是你自己跑出来的，改完必须重测。

陷阱二：一次改五处。 和重构同理，但优化更危险——你分不清是哪一处带来提升。万一某处其实让程序变慢，被另一处提升掩盖，根本发现不了。一次改一处，改完就量。

陷阱三：优化了功能，忘了验证正确性。 最惨的一种：代码从 12 秒变 1 秒，但导出数据错了。性能优化常动数据处理逻辑——批量可能漏数据、缓存给旧数据、并发乱序。第 77 篇那张”行为快照表”，优化场景同样必须做，而且要更严格：优化后的正确性验证，比重构还重要。

六、一张随身判断表

□ 用户真的抱怨了吗？没有 → 停，别改
□ 慢到几秒？3 秒以内 → 大概率不用改
□ 我测量过了吗？没有 → 先去测，别猜
□ 最慢那段占比多少？不到 50% → 改它收益有限
□ 能用"少"解决吗？能 → 优先，代价最低
□ 要用"缓"吗？数据旧了会出事吗？
□ 要用"批"吗？一条失败整批怎么办？
□ 要用"延"吗？后台失败了谁来管？
□ 改完可读性变差了吗？变差 → 补三样：为什么/数字/何时可删
□ 改完我重新测了吗？
□ 改完验证数据还是对的吗？（比性能更重要）
□ 现在速度够用了吗？够了 → 停手

提示词模板盒子

模板一：先测量（永远的第一步）

下面这段代码执行很慢，用户点击后要等约 __ 秒。

【本轮只做一件事：帮我测量，不要优化】
1. 在关键节点插入耗时统计，把流程拆成若干段，分别打印每段耗时
2. 告诉我应该重点关注哪几段
3. 给我完整文件（含插入的计时代码）
4. 告诉我：测完怎么读这些数字，什么占比才算"这就是瓶颈"

【代码】
（在此粘贴完整文件）

模板二：方案对比（要表格，不要代码）

我已经测量过了，耗时分布如下：
（贴出各段耗时）
最慢的是【____】这一段，占总耗时约 __%。

【本轮要求 · 重要】
1. 只针对最慢这段给方案，其他部分一律不讨论
2. 不要给我代码，先给【方案对比表】，至少 3 个方案，含：
   方案 | 具体手段 | 预估效果 | 可读性代价（低/中/高） | 引入的新风险 | 实现难度
3. 明确标出你推荐哪个，以及为什么
4. 特别说明：哪些方案会改变数据正确性/一致性/实时性
5. 若属"用空间换时间"，说明大概多占多少内存

【我的情况】
数据量大约：____   使用人数：____   技术水平：新手，优先好理解、风险低的方案

模板三：执行与验收（带正确性护栏）

我选择方案【__】，请帮我实现。

【铁律】
1. 只改这一处，其他任何地方不要动
2. 性能可提升，但【数据正确性绝对不能变】——同样输入必须得到完全一样输出
3. 若优化让代码变难懂，必须补注释说明：为什么这么写（原来慢在哪多慢）、优化前后耗时数字、什么情况可删这优化
4. 若引入缓存，明确告诉我：缓存多久过期、数据变更时怎么失效

【交付要求】
1. 完整文件，不要片段
2. 末尾用表格列出：改了哪几行 | 改成什么 | 为什么
3. 单独列出：改完我必须重点测哪几种情况（尤其易错边界）

【验收】这是优化前【A】和优化后【B】，请严格检查：
1. 【正确性】所有输入下输出是否一致？特别查空数据/单条/超大量/特殊字符
2. 【遗漏】A 里哪些判断/异常处理在 B 里被省略了
3. 【新风险】B 引入了哪些 A 没有的失败可能（缓存不一致/批量部分失败/并发冲突）
4. 【可读性】给 B 可读性 1-10 打分，说明比 A 差在哪
5. 一句话结论：这次优化"划算"还是"不划算"
【A】（粘贴）【B】（粘贴）

下篇预告

两把刀到手：第 77 篇重构（擦干净，只赚不赔）、第 78 篇优化（跑得快，有得有失）。但都共一个前提——你得知道”改完到底有没有改坏”。手工快照表太累还爱偷懒。下一篇《第 79 篇：用 AI 写单元测试》讲怎么让机器自动盯。下篇见。