PHP 8.5.7 不存在，官方最新稳定版是 PHP 8.4.6（2024年11月发布），PHP 8.5 尚未官宣；所谓“8.5.7 并发锁竞争”前提错误，实际需在 PHP 8.4.x 下解决 Symfony 分布式锁的 Redis 拓扑适配与原子性保障问题。
PHP 8.5.7 并不存在——官方最新稳定版是 PHP 8.4.5（2024年11月发布），而 PHP 8.5 尚未进入开发路线图。所谓“PHP 8.5.7 的并发锁竞争”是个前提错误，实际要解决的是 Symfony 应用在真实 PHP 版本（如 8.4.x）下，分布式场景中的锁竞争问题。
Symfony Lock 组件不依赖 PHP 版本，但依赖 Redis 部署模式
Symfony\Component\Lock\LockFactory 默认使用 RedisStore，但它在哨兵或集群环境下会失效，不是因为 PHP 版本升级，而是 Redis 拓扑结构变化导致原子性被破坏。
-
SET key value EX seconds NX是单节点命令，Redis Cluster 会把lock:order:123和lock:order:123:signal分到不同 slot，PUBLISH 失效 - 哨兵模式下，主从切换期间可能返回旧 master 响应，
NX语义丢失，两个客户端同时拿到锁 - PHP 8.4+ 对类型更严格，
$lock->acquire()返回bool，但旧代码常忽略判断直接往下走，导致逻辑错乱
如何让 Semaphore 行为真正“互斥”
Lock 组件的 acquire() 只是加锁入口，真正保障互斥的是后续的续期与释放策略，不是函数调用本身。
- 必须显式检查
$lock->acquire()返回值：if (!$lock->acquire()) { throw new RuntimeException('Lock failed'); } - 长任务中每
ttl/2调一次$lock->refresh()，并校验返回值：if (!$lock->refresh()) { /* 中断执行 */ } - 释放必须放在
try...finally块里，不能靠__destruct——FPM 进程异常终止时析构函数不保证执行 - 避免用业务 ID 直接作锁名，如
'order_123'；应加哈希标签：'{order_123}:process'，确保所有相关 key 落在同一 slot
SyncSemaphore 类完全不适用于 Web 场景
SyncSemaphore 是 PECL sync 扩展提供的本地信号量，基于系统共享内存或文件，只在单机、多线程 SAPI（如 Apache prefork）下有效。PHP-FPM 是多进程模型，每个 worker 有独立内存空间，SyncSemaphore 在不同请求间完全不共享状态。
立即学习“PHP免费学习笔记（深入）”；
-
new SyncSemaphore('mykey', 3)在进程 A 中初始化，在进程 B 中是全新实例，计数互不影响 - 该类已多年无维护，PECL sync 在 PHP 8.2+ 上存在兼容风险，官方文档明确标注“not recommended for production”
- 试图在 Eloquent 模型里定义
$semaphore属性或getSemaphoreAttribute，只是普通对象属性自增，和并发控制无关
真正关键的不是选哪个类，而是确认你的锁是否跨进程可见、是否原子更新、是否带自动过期。Redis 的 INCR+EXPIRE 或 Lua 脚本封装才是可靠起点，Symfony Lock 只是帮你做了这层封装——前提是它用对了 Store 和 key 结构。
