JavaScript 前端无法直接实现服务端分布式锁，需依赖后端接口协作完成加锁、校验与释放；核心是通过 /api/lock/acquire、/api/lock/check、/api/lock/release 三个 API 实现资源互斥访问。
JavaScript 中无法直接实现服务端级别的分布式锁，但可以通过 HTTP 请求配合后端接口，在多人协作场景中完成锁的申请、校验与释放。核心思路是：所有前端操作前先向后端发起“加锁请求”，获得许可后再执行编辑等敏感操作，完成后主动释放锁。
后端需提供三个关键接口
前端 JavaScript 的锁机制依赖后端支持，必须有以下 API：
- /api/lock/acquire：尝试获取锁，传入资源 ID（如文档 ID）和用户标识，成功返回锁令牌（token）或锁持有者信息；失败返回 409 Conflict 或自定义错误码
- /api/lock/check：轮询或按需查询某资源当前是否被锁定，返回 { locked: true, owner: "user123", expiresAt: "2025-04-05T10:30:00Z" }
- /api/lock/release：携带 token 或资源 ID + 用户 ID 主动释放锁（建议带签名或短期有效 token 防伪造）
前端用 fetch 实现带重试的加锁逻辑
避免竞态，加锁需设置超时与有限重试。例如用户点击编辑按钮时：
async function acquireLock(resourceId, userId, maxRetries = 3) {
const url = '/api/lock/acquire';
for (let i = 0; i <= maxRetries; i++) {
try {
const res = await fetch(url, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ resourceId, userId })
});
<pre class="brush:php;toolbar:false;"> if (res.status === 200) {
const { token, expiresIn } = await res.json();
return { success: true, token, expiresAt: Date.now() + expiresIn * 1000 };
}
if (res.status === 409) {
if (i < maxRetries) await new Promise(r => setTimeout(r, 800 * (i + 1)));
else throw new Error('资源已被他人锁定');
} else {
throw new Error(`加锁失败: ${res.status}`);
}
} catch (err) {
if (i === maxRetries) throw err;
await new Promise(r => setTimeout(r, 500));
}} }
编辑中定时续锁 + 离开前自动释放
防止因页面意外关闭导致锁长期占用，建议：
立即学习“Java免费学习笔记（深入）”；
- 加锁成功后启动定时器，每隔 expiresIn / 2 时间调用续锁接口（如 /api/lock/refresh），延长有效期
- 监听
beforeunload和visibilitychange，在用户切走或关闭页签前尝试释放锁（注意：此操作不保证 100% 成功，仅尽力而为） - 后端应设置锁的自动过期时间（如 3 分钟），避免单点故障导致死锁
UI 层实时反馈锁状态
提升协作体验，前端需及时同步锁信息：
- 进入页面时立即调用
/api/lock/check，显示“xxx 正在编辑中”及倒计时 - 加锁成功后禁用提交按钮，启用“保存”“撤销”等操作，并显示“您已获得编辑权”
- 若后台通知（如 WebSocket 或长轮询）发现锁被他人抢走，立刻弹出提示并置为只读模式
不复杂但容易忽略的是锁的粒度设计——按文档、章节还是字段级加锁，直接影响并发体验和实现成本。多数协作场景从文档级开始即可，后续再按需细化。
