第 8 章 缓存与性能：快，是设计出来的

性能这门课的第一定律听起来像偷懒：**最快的工作，是不做的工作。**缓存（Cache）就是这条定律的化身——把算过的答案记下来，下次直接给。

其实你已经在这套系统的四层里分别见过它了，串起来看：浏览器缓存——静态文件存在访客本地，所以"强制刷新"（Ctrl+Shift+R）这个动作才存在；CDN 缓存——第 1 章 Cloudflare 把答案存在离访客近的节点；应用层缓存——程序把耗时的计算结果记在内存里（认个脸：Redis，一个专职记答案的内存数据库，见到不慌）；往宽了说，第 5 章的索引也是同族——都在用空间换时间。

缓存的代价只有一个，但很大：答案可能是旧的。TTL（第 1 章的老朋友）是答案的保质期；Purge / 失效，是主动把旧答案扔掉。行业里有句老话，说计算机科学只有两大难题，其中一个就是缓存失效——所以"我明明改了，怎么还是旧的"是全行业共享的痛。排障口诀：从近到远清——先强刷浏览器，再 Purge CDN，最后看应用层。

第二定律：**先测量，再优化。**凭感觉优化等于闭眼开枪。三个测量点从近到远：浏览器 F12 的 Network 面板（哪个请求最慢？）；Vercel 或服务器日志里的耗时；数据库的慢查询记录（Supabase 面板能看）。再给你一张粗糙但救命的量级直觉表：读内存是纳秒级，同机房查一次数据库是毫秒级，跨洋一个网络来回是上百毫秒级。看懂这张表就明白——**慢，几乎从来不慢在你的循环和计算里，而是慢在网络往返的次数和没走索引的查询上。**所以性能优化的前三板斧永远是：少跑几趟（把三个请求合成一个）、给查询铺索引（第 5 章伏笔回收）、给不变的东西上缓存。

最后一条平衡性的话：没有测量数据、没有用户抱怨之前，不要优化。过早优化偷走的是做功能的时间。我们的原则是——先让它对（第一册第 14 章），再让它稳（本册第 3、9 章），最后才让它快，而且只快该快的地方。

出事时想起我

"我改了怎么没生效"——缓存三连清，从浏览器到 CDN；"第一次打开慢、之后飞快"——冷缓存现象，正常；"越用越慢"——数据涨了，去抓缺索引的查询；"时快时慢"——多半是链条里某个外部 API 在抖，去日志里看耗时分布（下一章的活）。

关键领悟

快的秘诀不是更努力地算，而是少算（缓存）、少跑（合并往返）、走目录（索引）——而这一切开始之前，先测量。

试一试（安全档：只读）

F12 打开 Network 面板，刷新我们的网站，按耗时排序。回答三个问题：最慢的三个请求是谁？哪些标着"（来自缓存）"？最慢那一个，慢在哪一层——DNS、网络、还是服务器处理（点开能看到分段耗时）？把这个请求的故事讲给爸爸听。