必须确认Redis连接可用，否则本地并发测试无法验证锁逻辑；常见错误为ECONNREFUSED，应通过redis-cli ping、docker ps检查进程，并确保Node客户端配置正确host、port及password，且加锁释放均需原子操作。
本地并发测试前必须确认 Redis 连接可用
VSCode 里跑 Node 测试脚本，如果 redis 客户端连不上，所有锁逻辑都测不出来——不是代码问题，是环境没通。常见表现是 Error: connect ECONNREFUSED 127.0.0.1:6379。
检查步骤：
- 先在终端执行
redis-cli ping，返回PONG才算 Redis 进程真在跑 - 若用 Docker 启动，确认容器没退出：
docker ps | grep redis - VSCode 的 Node 脚本里，
new Redis({ host: '127.0.0.1', port: 6379 })中的 host 不要写成localhost（某些 macOS 网络栈下解析慢或失败） - 如果 Redis 配置了密码，
new Redis({ password: 'yourpass' })必须显式传，否则连接成功但后续命令被拒绝
并发压测脚本别用 setInterval 模拟多客户端
用一个进程里开多个 setInterval 去“模拟并发”，本质还是单线程轮询，根本测不出分布式锁的真实竞争行为——Redis 锁的争抢发生在网络请求层面，不是 JS 事件循环里。
正确做法是启动多个独立进程：
- 写一个最小锁测试脚本
lock-test.js，只做“尝试加锁 → 执行临界区 → 释放锁”三步 - 用 shell 并发拉起：
for i in {1..10}; do node lock-test.js & done - 或用
concurrently：npx concurrently "node lock-test.js" "node lock-test.js" "node lock-test.js" - 关键：每个进程必须创建自己的
Redis实例，不能共用一个 client 对象（否则锁 key 冲突、释放错乱）
加锁必须用 SET key value NX EX 秒数原子操作
Node.js 里如果分两步调 client.set(key, value) + client.expire(key, secs)，在高并发下大概率出现锁没过期就永久存在——第二步可能因网络抖动失败，而第一步已成功。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
必须合并为原子命令：
- 推荐用
client.set(key, value, { EX: 5, NX: true })（ioredis 或 redis@4+ 支持） - 老版本驱动（如 redis@3）只能靠 Lua：
client.eval("return redis.call('SET', KEYS[1], ARGV[1], 'NX', 'EX', ARGV[2])", 1, key, value, "5") -
NX保证只在 key 不存在时设值，EX同步设过期，缺一不可 - value 必须是当前客户端唯一标识（比如
process.pid + '-' + Date.now()），否则释放锁时无法校验所有权
释放锁必须校验 value 再 DEL，否则会误删别人锁
直接 client.del(lockKey) 是危险操作——A 进程的锁超时自动释放后，B 进程刚拿到锁，A 又执行了 DEL，就把 B 的锁干掉了。
释放必须用 Lua 原子脚本校验 value：
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
end
对应 Node 调用：
- ioredis：
client.eval(luaScript, 1, lockKey, lockValue) - redis@4：
client.eval(luaScript, { keys: [lockKey], arguments: [lockValue] }) - 返回值为
1表示删除成功，0表示锁已被别人持有或已过期，此时不应报错，而是跳过释放逻辑
本地并发测算真正难的不是写锁，是让多个进程真实、随机地在同一毫秒级窗口抢同一个 key；一旦漏掉 value 校验或非原子加锁，测出来的“成功率”全是假阳性。
