必须用set key value nx ex原子命令加锁，因setnx+expire非原子，webman多worker下易留永不过期死锁；解锁须lua校验value后删除，防止误删；value需含pid和uniqid确保唯一，锁应加在db操作逻辑块而非命令入口，key须含时间维度且所有实例连同一redis db。
Webman 多实例部署下，不加分布式锁就跑定时任务或共享写操作，必然重复执行、数据错乱——这不是概率问题，是确定性事故。
为什么 setnx + expire 组合在 Webman 里绝对不能用
Webman 基于 Swoole，worker 进程常驻内存，网络延迟或协程中断时，setnx() 成功但 expire() 失败，就会留下一个无过期时间的 key。这个 key 不会自动消失，后续所有加锁请求都失败，整个业务卡死。
- 必须用原子命令：
$redis->set($key, $value, ['NX', 'EX' => $ttl]) -
$value不能是固定字符串（如'1'），必须带上下文唯一性，推荐getmypid().'_'.uniqid('', true) - Webman 的多 worker 场景下，只用
uniqid()有极小概率碰撞，拼上getmypid()才真正隔离
定时任务去重，锁要加在“处理逻辑块”，不是命令入口
很多人把锁写在 php webman task:run --name=sync_order 的 handle 方法开头，这是无效的：命令行启动的是全新 PHP 进程，getmypid() 和 uniqid() 完全不可控，不同实例生成的 $value 可能相同，导致锁校验失效。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 真正该加锁的位置，是 DB 查询/更新那几行代码之前，例如
Db::table('orders')->where('status', 'pending')->update(...)前 -
$key必须含时间维度，比如task:sync_order:20260525或task:sync_order:hour_12，避免昨天和今天的任务互相干扰 - 所有 Webman 实例必须连同一个 Redis DB（注意不是不同 cluster 分片），否则锁根本不同步
解锁必须走 Lua 脚本，GET + DEL 是危险幻觉
直接 $redis->del($key) 看似简单，但在 Webman 长耗时任务中极易出事：A 拿到锁，执行慢超时，Redis 自动删 key；B 紧接着抢到锁开始执行；A 此时刚好完成，调用 del —— 删掉的是 B 的锁。
- 正确解锁方式：
$redis->eval("if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end", 1, $key, $value) - 如果所用云 Redis 禁用
EVAL（如某些阿里云 Redis 社区版），只能退化为 GET 校验后 DEL，但必须把$ttl设得足够长（比如任务最长可能耗时 300 秒，$ttl至少设 600），用时间换安全余量 - 别信“我测试了几十次都没问题”——竞态窗口极小，但线上一旦触发就是批量数据错误
Webman 连接池与锁生命周期的隐性冲突
Webman 使用 webman/redis 扩展时，默认连接池复用连接。但如果加锁和解锁不在同一个协程上下文（比如锁在主协程加，解锁在 Timer::after 回调里），可能拿到不同连接，而 Lua 脚本的原子性依赖单连接上下文。
- 确保加锁和解锁使用同一个
Redis实例对象（例如通过 DI 容器注入或静态缓存） - 不要在
onWorkerStart里 new Redis 并赋给全局变量，Swoole 多进程间无法共享资源，会导致连接错乱或序列化失败 - 若任务需异步解锁（如失败后延迟重试），建议把
$key和$value传进回调，仍用同一个 Redis 实例执行 Lua
最易被忽略的一点：Webman 的定时任务往往由系统 crontab 触发，但实际执行逻辑在 worker 进程内——这意味着锁的持有者是 worker，不是 crontab 进程。一旦 worker 重启或 reload，锁可能残留，所以 $ttl 不仅要大于业务耗时，还得预留进程启停缓冲时间。
