hyperf 中防止批量修改重复提交需用分布式锁，锁 key 应基于排序后 id 列表哈希及业务上下文生成，配合 owner 校验的 lua 脚本加解锁，并设合理 ttl 与续期机制。
在 Hyperf 中防止批量修改请求重复提交，核心是用分布式锁控制“同一组数据在同一时刻只能被一个请求修改”。这比单条记录防重更复杂，因为要锁定的是数据集合（比如一批订单 ID、用户 ID 列表），而不是单个资源键。
锁粒度要匹配业务语义
批量操作的锁不能简单用固定 key（如 batch:update:lock），否则会变成全局串行，严重拖慢吞吐。正确做法是基于请求特征生成唯一锁 key：
- 对传入的 ID 列表排序后拼接哈希，例如：
batch:update:user:sha256("1001,1002,1005") - 若含业务上下文（如租户 ID、操作类型），应一并纳入：
batch:update:tenant_123:role_assign:sha256("u1,u2,u3") - 避免直接用原始 ID 字符串作 key（顺序不固定会导致不同 key 锁同一组数据）
用 RedisLock + Lua 脚本确保安全释放
Hyperf 自带的 Redis::set($key, $value, ['NX', 'EX' => $ttl]) 可加锁，但解锁必须原子验证 owner，否则可能误删他人锁。推荐封装成带 owner 校验的 Lua 脚本：
- 加锁时生成唯一 owner（如
uniqid('batch_', true)），存入 value - 解锁执行 Lua：
if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end - Hyperf-wise-locksmith 库已内置该逻辑，可直接调用
$locker->redisLock($key, $callback, $ttl)
设置合理 TTL 并考虑续期场景
批量修改耗时波动大，TTL 不能拍脑袋定。建议：
- 按历史 P99 耗时 × 1.5 设置基础 TTL（如平均 800ms，设为 2 秒）
- 若操作中需调用外部接口或数据库批量更新，且可能超时，应在关键节点调用
renewLock()延长过期时间 - 避免 TTL 过长（>30 秒）——影响故障恢复速度；也不宜过短（
失败处理要区分“锁冲突”和“业务异常”
拿到锁失败 ≠ 操作失败，而是说明另一请求正在处理相同数据集：
- 直接返回明确提示：“当前批量操作已在进行中，请稍后重试”，而非 500 或静默失败
- 不自动重试（尤其前端无感知时），避免雪球效应
- 可记录日志：锁 key、owner、冲突时间，用于事后分析热点批次
