javascript本身不支持分布式锁，必须依赖redis等外部系统；应使用set命令原子加锁、lua脚本安全释放，并通过看门狗续期、封装工具类、后端统一管控来保障可靠性。
JavaScript 本身不直接支持分布式锁，因为它运行在单机环境（浏览器或 Node.js 进程），而分布式锁需跨多个服务实例、保障多节点间互斥访问共享资源。真正实现分布式锁必须依赖外部协调系统（如 Redis、ZooKeeper、etcd）。在接口调用中处理“抢占与释放”，核心是：**用服务端（Node.js）封装原子化的加锁/解锁逻辑，并确保业务代码在持有锁期间执行、异常时仍能释放锁**。
用 Redis 实现可靠的加锁（SETNX + Lua 原子操作）
推荐使用 Redis 的 SET key value EX seconds NX 命令，它具备原子性：仅当 key 不存在时设置成功，同时指定过期时间，避免死锁。
- 锁的 value 必须唯一（例如使用 UUID 或 service_id + process_id + timestamp），用于校验是否为当前请求所持，防止误删他人锁
- 不要用
SETNX + EXPIRE两步操作——中间可能崩溃导致无过期时间 - 加锁失败应明确返回（如 HTTP 423 Locked），而非无限重试，避免雪崩
- 示例（Node.js + ioredis）：
const lockKey = `lock:order:${orderId}`;
const lockValue = uuidv4(); // 唯一标识
const expireSec = 10;
<p>const result = await redis.set(lockKey, lockValue, 'EX', expireSec, 'NX');
if (result === 'OK') {
try {
// 执行受保护的业务逻辑（如扣减库存、生成订单）
await handleOrder(orderId);
} finally {
// 必须用 Lua 脚本安全释放：先校验 value 再 del
await redis.eval(
"if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end",
1,
lockKey,
lockValue
);
}
} else {
throw new Error('Lock not acquired');
}</p>避免常见陷阱：自动续期与锁失效边界
如果业务耗时可能超过锁过期时间（如复杂计算、下游调用慢），需引入看门狗（watchdog）机制自动续期。
- 加锁成功后，启动一个后台定时器（如 setInterval），每隔 expireSec / 3 时间尝试用 Lua 脚本延长 TTL（仅当 value 匹配才更新）
- 业务执行结束或抛错时，清除定时器并立即释放锁
- 注意：Node.js 的异步 I/O 不会阻塞续期定时器，但若进程崩溃或被 kill，续期即失效，所以过期时间仍是兜底关键
封装成可复用的锁工具类（带上下文与超时控制）
将加锁、执行、释放、续期封装为 Promise API，降低业务层心智负担。
- 支持传入最大等待时间（waitTimeout）、锁有效期（leaseTime）、重试间隔（retryInterval）
- 内部自动处理「等待 → 尝试获取 → 续期 → 清理」全链路
- 业务只需写核心函数：
await distributedLock.acquire('res:123', async () => { /* do work */ }) - 务必记录加锁/释放日志，便于排查锁争用或泄漏
不推荐前端 JS 处理分布式锁
浏览器端 JavaScript 无法直连 Redis 或 ZooKeeper，也无法保证请求原子性；所谓“前端加锁”只是伪需求，实际应由后端接口统一收口。若需防重复提交，应在前端做按钮禁用 + 防抖，再配合后端幂等设计（如 token 机制、唯一业务 ID）与分布式锁协同，而非把锁逻辑下沉到客户端。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
