如果你发现同一个页面的执行时间忽高忽低，而数据库查询次数明显多于页面上真正需要的数据量，问题多半不在主题有多复杂，而在同一份结果被反复算出来。WordPress 为这件事留了一个接口：transient。理解它为什么该缓、以及缓了之后该怎么验证，比装任何插件都更接近问题本身。 如果查询结果反复计算，随后再用WordPress 数据库膨胀排查清单核对数据规模和无用记录。
transient 缓存的到底是什么
它缓存的是"算出来的中间结果"，不是页面、不是图片、也不是用户数据。典型场景有三个：一次远程接口请求的返回、一段需要遍历大量数据才能得到的聚合结果、以及同一页面上多个区块都要用的那份列表。缓存的价值在于把"每次请求都重算一遍"变成"算一次，用到过期为止"。
要说明的是接口定位：WordPress 官方的 API 手册把这类能力按分册记录，目录里就有 Transients 这一项，和 Options、Metadata、Database API 并列。它是给主题与插件用的数据存取约定，WordPress 官方没有就它能带来多少性能收益给出承诺，也没有公布任何"缓存多少条最合适"的阈值，收益完全取决于你缓存的东西有多贵。
没有外部对象缓存时，它落在哪
这是最关键的一层差异。transient 是一层接口，不是一个存储引擎：如果站点没有接外部对象缓存，读写会落到数据库里的选项表上，于是每次取缓存都变成一次查库，缓存本身又成了负载来源。只有在接上外部对象缓存之后，transient 才真正变成"从内存或独立缓存层里拿数据"。这解释了一个常见现象：装了对象缓存之后页面明显变轻，但如果你同时在做页面级缓存，这个收益容易被掩盖掉。
从性能角度看这件事有个官方口径可以对齐。web.dev 的 Web Vitals 说明把 TTFB（首字节时间）和 FCP（首次内容绘制）列为辅助指标，并写明它们的价值在于诊断 LCP 时遇到的"服务器响应慢"这类问题。缓存重复计算的结果，作用就落在这条链路上：TTFB 降下来，LCP 才有空间达标。
哪些该缓、哪些不能缓
- 先按"算一次要多久"排序。远程接口、聚合查询、跨表的统计优先；一次算术、一条主键查询不要缓存，缓存的读写成本可能比再算一次还高。
- 给每条缓存写清楚"什么时候算过"，否则过期逻辑没法验证，脏数据会一直留在那里。
- 把时间敏感的量和结构性的量分开：站点设置、菜单结构、分类树这类变动很少的适合长一点过期；库存、价格这类必须短的，就别缓存或只缓存很短。
- 跟用户身份绑定的数据，不要放进所有人都共用的那一份缓存里，这是最常见的串数据原因。
- 失效点要显式定义：内容改动、设置变更、定时任务跑完之后，该清的缓存要能被清掉。
- 缓存键要带上会改变结果的维度，比如语言、币种、页面类型，键名撞车比缓存未命中更难查。
如果只做一件事，就做第 1 步的排序。缓存命中率低而缓存对象很便宜的系统，越缓存越慢，这类案例比缓存不生效的案例更隐蔽。web.dev 讲最有效的优化做法那篇里也把"就近分发加缓存"列为降低首字节时间的主要手段，方向是一致的：让重复请求不必再从头算。
什么时候不值得为它折腾
四种情况可以先停手。一是站点本来就没什么重复计算：页面数少、模板简单、每次请求只查十几条数据，上缓存层带来的运维成本高于收益。二是瓶颈根本不在数据库：把执行时间拆开看，如果时间花在远程接口上，缓存自己也算不出来什么。三是页面级缓存已经覆盖了绝大部分请求，动态层被命中得很少。四是托管环境不允许你挂持久化对象缓存，或者只能在共享主机上装，这种情况下"接对象缓存"往往变成不可持续的方案。
还有一条边界要记住：核心网页指标只有 LCP、INP、CLS 三项，官方阈值分别是 2.5 秒、200 毫秒、0.1，按第 75 百分位衡量、移动与桌面分开；TTFB 只是辅助诊断指标。缓存让首字节时间变好是手段，不要把它当成有官方背书的排名承诺。
怎么确认缓存真的在工作
验证分三步。第一步查存在性：确认目标缓存键确实有值，而不是每次都写进去又立刻判定过期——那是最常见的失效形态。第二步查复用：连续访问同一页若干次，确认查询次数不再随访问次数线性上涨，而是稳定在某个水平。第三步查新鲜度：手动清掉一条缓存，再访问一次，确认它能被重新算出来，且算出来的内容与清空前一致。
最后看真实数据的走向：按 URL 分组确认这一组的状态变化，并确认移动与桌面两端都没有被牺牲。整体提速的先后顺序，站内旧文加速先选插件还是调服务器和缓存、数据库与前端文件的按需优化已经拆过顺序，本文只补"怎么验证"这一层。
