秒级缓存失效在 Symfony 中需满足1–30秒可靠过期，关键在于选用 Redis 驱动、启用 use_lua:true、禁用 lazy:false、避免共享内存污染，并统一使用 expiresAfter() 设置整数秒 TTL。
秒级缓存失效在 Symfony 中不是开箱即用的默认行为，因为 PSR-6/PSR-16 规范本身不支持亚秒级 TTL（如 0.5 秒），且底层适配器（Redis、PDO、File）对 sub-second 精度的支持差异极大。真正可行的“秒级”指 **1–30 秒区间内可靠失效**，关键在于选对驱动、绕过精度陷阱、并规避 FrankenPHP 的进程模型副作用。
Redis 适配器必须启用 redis.use_lua 并禁用 lazy 模式
默认 Redis 缓存池（cache.adapter.redis）在高并发下可能因 Lua 脚本未启用而出现 TTL 偏差——尤其当多个请求几乎同时写入同一 key 时，Redis 的 SETEX 命令无法原子覆盖旧 TTL，导致实际过期时间漂移数秒甚至更久。
解决方法是强制使用 Lua 脚本保障原子性，并关闭连接复用带来的状态干扰：
- 在
cache.yaml中显式配置：framework: cache: pools: cache.app: adapter: cache.adapter.redis provider: 'redis://localhost' # 必须添加以下两行 options: use_lua: true lazy: false -
use_lua: true启用EVAL脚本，确保SET+EX原子执行 -
lazy: false防止 FrankenPHP 的多线程 SAPI（如frankenphp-worker）中连接复用导致的 pipeline 冲突和 TTL 覆盖丢失 - 验证是否生效：用
redis-cli查看 key 的 TTL，写入后立即TTL your_key，确认返回值稳定在设定秒数 ±0.2s 内
FrankenPHP 下避免 cache.app 共享内存污染
FrankenPHP 默认以多线程模式运行 PHP Worker，cache.app 若使用 cache.adapter.php_array 或未隔离的 APCu 驱动，会导致不同请求间缓存互相覆盖——尤其在秒级 TTL 场景下，A 请求刚设的 key=foo, ttl=5，B 请求 2 秒后读取并误判为“未命中”，重新生成再写入，造成重复计算和数据不一致。
立即学习“PHP免费学习笔记（深入）”；
正确做法是强制每个 Worker 进程拥有独立缓存空间：
- 绝不使用
cache.adapter.php_array或cache.adapter.apcu作为cache.app主池（它们是进程内共享的） - 改用 Redis 或 Memcached，哪怕单机部署——它们天然跨进程隔离
- 若必须用本地内存，可基于
getmypid()构造唯一前缀：$pid = getmypid(); $cache = new PhpFilesAdapter("app_{$pid}", 5); // TTL 设为 5 秒但该方案需自行管理清理，不推荐生产使用
CacheItem::expiresAfter() 是唯一安全的秒级设置入口
Symfony 的 CacheItem::expiresAt() 接收 \DateTimeInterface，在 FrankenPHP 的多线程环境下，系统时钟微小抖动（尤其是容器化部署）可能导致同一批请求生成的 expiresAt 时间戳错乱，最终使部分 key 提前或延后失效达数百毫秒。
而 expiresAfter(5) 直接传入整数秒，由适配器在写入时调用 time() + $seconds 计算绝对时间，路径更短、受干扰更少：
- ✅ 正确写法：
$item = $cache->getItem('user_profile_'.$userId); $item->set($data)->expiresAfter(8); // 稳定 8 秒 $cache->save($item); - ❌ 避免写法：
$item->expiresAt((new \DateTime())->modify('+8 seconds'));——modify()依赖当前时钟，且DateTime序列化过程在 FrankenPHP 中可能引入额外延迟 - 注意：
expiresAfter()的参数必须是整数，传浮点数（如8.5）会被截断为8，不会报错但失去精度
秒级缓存真正难的不是设 TTL，而是保证“所有 Worker 进程看到同一份过期逻辑”。Redis + Lua + 显式 expiresAfter() 是目前 FrankenPHP 环境下最可控的组合；任何试图用文件、APCu 或自定义时间戳的方案，都会在流量突增时暴露竞态问题。
