PHP 老项目加缓存时，先画清楚读写路径

给老 PHP 项目加缓存，表面上看很像一件“性能补丁”工作：慢了就加缓存，数据库忙了就挡一层。
可 2016 年我自己在碰这类改造时，最大的感受不是技术难，而是很多老项目根本没人能完整说清楚数据到底是怎么读出来、又是从哪里被改掉的。

如果这条路径没先画清楚，缓存加进去之后，系统只会更像黑箱。

为什么老项目特别容易踩这个坑

因为老 PHP 项目里很常见这种情况：

• 同一份数据被多个入口读取
• 更新动作散在后台、脚本和接口里
• 页面层顺手做了一些字段加工

在这种背景下，缓存不是单纯的技术组件，而是在插手一条原本就不透明的业务路径。

我后来会先做什么

不是先选 Redis 还是文件缓存，也不是先估 TTL，而是先回答：

• 这份数据是谁在读
• 谁会更新它
• 更新后谁负责让缓存失效
• 如果缓存 miss，回源是不是稳定

把这四件事写清楚之后，很多本来模糊的问题会提前暴露出来。

画路径的价值

一旦读写路径画出来，你会发现有些接口根本不适合先加缓存。
因为它们的问题也许不是查询慢，而是：

• 查询条件本来就不稳定
• 更新频率太高
• 返回结构依赖太多上下文

这种接口硬加缓存，短期可能有点效果，长期却会制造更多一致性问题。

小结

PHP 老项目加缓存，最重要的不是先接哪个中间件，而是先把读写路径看清。
2016 年我对缓存这件事越来越谨慎，就是因为见过太多“加完看起来更快，实际更难维护”的例子。路径清楚了再加缓存，风险会低很多。