缓存核心是命中、失效及时且不拖慢响应；仅适用于读多写少、变化不频繁、允许短暂过期的接口，如商品详情、配置列表；禁用场景包括订单状态、实时消息等；需按请求参数构造key、结构稳定；单机用APCu，集群用Redis；更新策略推荐先删缓存再延迟双删。
用缓存减轻 PHP API 压力，核心不是“加一层缓存”，而是让缓存真正命中、及时失效、不拖慢响应——否则反而增加延迟和内存开销。
判断哪些接口适合加缓存
缓存只对「读多写少、数据变化不频繁、允许短暂过期」的接口有效。比如商品详情、配置列表、地区字典；但用户订单状态、实时聊天消息、支付回调结果这类绝对不能简单缓存。
-
GET请求且无敏感参数（如user_id、token）才考虑全量缓存 - 带分页参数的接口（如
page=2&limit=10），需把完整查询字符串作为缓存 key 的一部分 - 返回 JSON 且结构稳定（避免缓存了空数组或 null 导致前端报错）
选对缓存方式：APCu vs Redis vs 文件缓存
本地缓存快但不共享，分布式缓存可共享但有网络开销。单机部署用 apcu_store() 足够；集群环境必须用 Redis，否则节点间缓存不一致。
-
apcu_store()适合高频、短时效（ -
Redis::setex()是最常用选择，支持自动过期、原子操作，key 建议带前缀如"api:product:123" - 别用
file_put_contents()做缓存——并发写入容易损坏文件，且 I/O 比内存慢 2~3 个数量级
绕不开的缓存穿透与雪崩问题
缓存穿透是查一个根本不存在的 ID（比如 /api/user/999999999），导致每次请求都打到 DB；缓存雪崩是大量 key 同时过期，DB 瞬间被压垮。
立即学习“PHP免费学习笔记（深入）”；
- 对空结果也缓存（如
Redis::setex("api:user:999999999", 60, "null")），但 value 要能区分“真空”和“查无此 ID” - 设置随机过期时间：基础 TTL 设为 300 秒，再加 ±60 秒抖动，避免集中失效
- 关键接口加
mutex锁：查不到缓存时，用Redis::set("lock:api:user:123", 1, ["nx", "ex" => 5])防止多个请求同时重建缓存
缓存更新策略：先删缓存，还是先改 DB？
写操作发生时，缓存必须失效或更新，否则一致性立刻破坏。推荐「删除缓存 + 延迟双删」而非更新缓存。
- 修改 DB 后立即
Redis::del("api:product:123")，下次读自动重建——简单可靠 - 如果 DB 更新失败，缓存没删，最多旧数据多活几秒；但如果删缓存失败而 DB 更新成功，就会永久脏数据
- 高一致性场景（如库存扣减）可在 DB 更新后，再删一次缓存（即「双删」），中间加
sleep(100)或异步队列确保主从同步完成
最难的从来不是加缓存，而是决定哪条数据该缓存多久、谁来负责清理、出错时怎么降级——这些逻辑一旦散落在各处，比没缓存还难维护。
