核心原则是环境决定后端、场景决定能力：开发用filesystemadapter（不依赖扩展、调试友好），单机高频元数据用apcuadapter（需apcu.enabled=1），分布式高可靠场景首选redisadapter（需规范dsn并启用redis.use_lua=1）。
选 Symfony 缓存适配器，核心就一条：**环境决定后端，场景决定能力**。开发用文件，生产看部署规模和数据敏感度——不是越“高级”的适配器越好，而是最匹配当前运行条件的那个才真正高效。
开发环境：FilesystemAdapter 是默认且推荐的选择
它不依赖任何 PHP 扩展，开箱即用，调试友好，缓存内容直接落盘可查。适合本地开发、CI 测试等无需高并发的场景。
- 确保
cache_dir指向一个 Web 根目录外、PHP 进程有写权限的路径（如%kernel.cache_dir%/pool），避免暴露在 public 下 - 不要在生产环境启用它——文件 I/O 在高并发下会成为瓶颈，且多进程写入可能丢数据或产生竞态
- 若需模拟标签功能，可用
TagAwareAdapter包裹它，但仅限验证逻辑，不用于真实压测
单机高性能场景：ApcuAdapter 最合适
适用于 PHP-FPM 单服务器部署，高频读、低一致性要求的元数据缓存，比如路由映射、配置片段、翻译目录索引。
- 确认
apcu.enabled=1，且 CLI 模式下不用（apc.enable_cli=0是安全默认） - 重启 PHP 进程即清空全部缓存，不适合存储用户会话或长期状态
- 搭配
TagAwareAdapter可实现快速批量失效，比 Redis 轻量，但无跨机器能力
分布式/高可靠场景：RedisAdapter 是首选
支持集群、哨兵、自动过期、原子操作与标签原生集成，是生产环境最通用、最稳健的选择。
- 连接字符串格式必须规范，如
redis://127.0.0.1:6379或rediss://（启 TLS），否则抛InvalidArgumentException - 启用
redis.use_lua=1（PHP Redis 扩展）能提升标签清除等复合操作的原子性 - 配合
TagAwareAdapter使用时，必须全程通过该包装器读写，不能混用底层RedisAdapter::save()
其他适配器使用前提
MemcachedAdapter 适合已有 Memcached 基础设施的大型系统，但标签支持弱于 Redis，建议只用于简单键值缓存；ArrayAdapter 仅限单元测试，每次请求新建，不跨请求；Doctrine PDO 缓存 是兜底方案——当 Redis/Memcached 不可用，又必须共享缓存时，才考虑用数据库表暂存查询结果，性能远低于内存方案。
