PHP 8.5.7 不存在，实际为 PHP 8.5.3 + Fiber + Symfony Lock；Lock 组件不自动适配 Fiber，因默认同步实现会阻塞 Fiber，需改用 ext-redis 非阻塞模式或自定义支持 yield 的 Store 实现。
PHP 8.5.7 并不存在——官方最高稳定版是 PHP 8.5.3（发布于 2026 年 4 月 19 日），所有关于 “8.5.7” 的讨论均属版本号误传或非官方打包。因此，你实际面对的是 PHP 8.5.3 + Fiber + Symfony Lock 的组合，而它的行为与“8.5.7”无关，但与 Fiber 启用方式、Lock 存储后端、以及 Symfony 版本强相关。
Fiber 模式下 Lock 组件是否自动适配？
不自动适配。Symfony Lock 组件本身是同步设计的，Symfony\Component\Lock\Lock 实例默认不感知 Fiber 上下文，也不会自动切换为 Fiber-safe 的 acquire/release 流程。它依赖底层存储（如 RedisStore、DatabaseStore）是否支持非阻塞调用——而目前 Symfony 官方 Store 实现全部基于同步 I/O，即使运行在 Fiber 环境中，$lock->acquire() 仍会阻塞当前 Fiber，而非让出控制权。
- Fiber 不等于自动异步：PHP 的 Fiber 是协作式调度，但 Lock 的底层驱动（如
Predis\Client或pdo_mysql）若未使用原生异步驱动（如ext-redis的非阻塞模式、amphp/mysql），就无法 yield -
RedisStore在ext-redis下表现尚可，因该扩展内部有轻量级轮询机制；但用Predis（纯 PHP 实现）则必然阻塞整个 Fiber 调度器 -
DatabaseStore基于 PDO，默认同步，且无yield接口，Fiber 中调用等同于阻塞线程
如何让 Lock 在 Fiber 环境中真正 yield？
必须绕过默认 Store，改用明确支持 Fiber/yield 的底层实现。目前可行路径只有两条：
- 用
ext-redis+RedisStore，并确保 Redis 连接启用redis.scan和非阻塞读写（需 PHP 编译时启用--enable-redis-sockets，且 Redis 配置timeout 0不生效，应设为合理值如5） - 自行实现
StoreInterface，底层调用Amp\Redis\Client或Swoole\Coroutine\Redis，并在acquire()内显式yield—— 例如：public function acquire(string $resource, int $ttl = 300): bool{ return (yield $this->client->set($resource, '1', ['nx', 'ex' => $ttl])) !== false;}
- 避免在 Fiber 中直接调用
LockFactory::createLock()，改用LockFactory::createSharedLock()+tryAcquire()组合，减少阻塞时间窗口
Symfony 7.1+ 是否修复了 Fiber 兼容性？
没有专门修复。Symfony 7.1+ 仅保证自身代码不破坏 Fiber 执行流（如不意外 throw 未捕获异常导致 Fiber 中断），但 Lock 组件未引入 Fiber-aware 抽象层。官方路线图中亦无 “Lock + Fiber” 专项计划。真正起作用的是底层扩展行为：
立即学习“PHP免费学习笔记（深入）”；
-
ext-redis 6.0+在 Fiber 环境中已能安全 yield，前提是 PHP 编译时启用了sockets支持 -
pdo_mysql仍完全同步，Fiber 中使用DatabaseStore等价于退化为单 Fiber 单连接模型，极易锁死 -
symfony/lock的RetryTillSaveStore包装器在 Fiber 下可能无限重试而不 yield，必须禁用或重写
最易被忽略的一点：Fiber 调度器本身不管理锁资源生命周期。一个 Fiber 获取锁后若被调度器挂起，而另一个 Fiber 尝试获取同一资源，不会触发自动释放——Lock 的 TTL 必须严格设置，不能依赖 Fiber 生命周期自动清理。
