不能直接用composer require cache/cache安装多级缓存，因为该包不存在；主流缓存库如symfony/cache仅提供单层抽象和ChainAdapter（多后端兜底），不内置L1/L2穿透逻辑，需手动实现回填、容量控制等热点分层机制。
为什么不能直接用 composer require cache/cache 装出多级缓存？
因为 PHP 官方没有叫 cache/cache 的 Composer 包，主流缓存库（如 php-cache/cache、symfony/cache）默认只提供单层抽象，不内置 L1/L2 分层逻辑。所谓“多级热点缓存”，本质是手动组合两个缓存实例：一个快但容量小的内存层（L1），一个慢但持久的后端层（L2），再加一层协调逻辑。
真正能开箱即用的方案极少，多数得自己写 MultiLevelCachePool 类或基于 PoolInterface 做封装。
用 symfony/cache 搭建 L1+L2 最简可行结构
symfony/cache 是目前最稳妥的选择——它实现了 PSR-6 和 PSR-16，支持嵌套池（ChainAdapter），但注意：ChainAdapter 是“多后端兜底”，不是“L1/L2 读写穿透”。要实现热点分层，必须手写代理逻辑。
- L1 推荐用
ArrayAdapter或PhpFilesAdapter（进程内，无序列化开销） - L2 推荐用
PdoAdapter或RedisAdapter（跨请求持久） - 关键点：L1 miss 后必须主动写回 L1，且需控制 L1 容量（否则内存爆掉）
示例核心逻辑：
立即学习“PHP免费学习笔记（深入）”；
use Symfony\Component\Cache\Adapter\{ArrayAdapter, RedisAdapter};
use Psr\Cache\CacheItemPoolInterface;
class L1L2CachePool implements CacheItemPoolInterface
{
private $l1;
private $l2;
private $l1MaxSize = 1000;
public function __construct(CacheItemPoolInterface $l1, CacheItemPoolInterface $l2)
{
$this->l1 = $l1;
$this->l2 = $l2;
}
public function getItem($key)
{
$item = $this->l1->getItem($key);
if ($item->isHit()) {
return $item;
}
$item = $this->l2->getItem($key);
if ($item->isHit()) {
// 热点回填 L1，但需防 L1 溢出（可加简单计数或 TTL 过滤）
if ($this->l1->hasItem($key) === false) {
$this->l1->saveDeferred($item);
}
return $item;
}
return $item;
}
// save() 和 delete() 同理需双写或按策略选择写入层
}
php-cache/cache 的 MultiLayerCachePool 为什么容易踩坑？
这个包确实提供了 MultiLayerCachePool，但它默认行为是“写入所有层 + 仅从 L1 读取”，看似省事，实际有严重隐患：
- 写放大：每次
save()都同步写所有层，L2 是 Redis 或 DB 时延迟陡增 - 一致性风险：L1 和 L2 TTL 不一致时，
getItem()可能返回过期数据（L1 未及时失效） - 无热点识别：不会自动把高频 key 提升到 L1，L1 容量全靠预设，容易被冷数据占满
如果真要用它，必须重写 getItem()，去掉 L1 自动 fallback，改为显式查 L1 → 查 L2 → 回填 L1 的流程，并禁用它的自动写入链路。
PHP-FPM 场景下 L1 必须用 ArrayAdapter 吗？
不一定，但绝大多数情况是。因为 PHP-FPM 每个 worker 是独立进程，ArrayAdapter 的内存只在当前请求生命周期有效，正好匹配“热点”定义（短时高频访问）。其他选项问题明显：
-
ApcuAdapter：虽跨请求，但 APCu 共享内存易被清理，且无法精确控制 L1 大小 -
PhpFilesAdapter：文件 I/O 开销大，不如ArrayAdapter直接，除非你明确需要跨 worker 共享 L1（极少见） - 自建静态数组：容易引发内存泄漏，且无 GC 机制，不推荐
真正要注意的是：别在 CLI 或 long-running 进程（如 Swoole）里盲目复用这套逻辑——ArrayAdapter 在长连接中会不断膨胀，必须加 LRU 或 TTL 清理。
