主题
第 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、网络、还是服务器处理？点开能看到分段耗时。把这个请求的故事完整讲给自己听一遍，讲不顺的地方，就是还没懂的地方。