broadcastchannel不能替代事务锁，因其不保证顺序、无原子性且不阻塞执行；需结合localstorage加时间戳实现轻量互斥锁，broadcastchannel仅作变更通知。
为什么 BroadcastChannel 不能直接替代事务锁
BroadcastChannel 只负责广播消息，不保证接收顺序、不提供原子性、也不阻塞执行。你发一条 lock_request 消息，多个窗口同时收到并各自去查 localStorage，结果可能全判自己“能上锁”，导致并发冲突。真正的授权必须有“唯一裁定者”——而这个角色不能由广播本身承担，得靠本地状态 + 显式竞争规则。
用 localStorage + timestamp 实现轻量级互斥锁
核心思路：所有窗口共用一个 localStorage 键（如 __singleton_lock），写入时带时间戳和窗口 ID，读取时只认“最新且未过期”的锁记录。BroadcastChannel 仅用于通知其他窗口“锁已变更”，不参与决策。
- 申请锁前先用
Date.now()生成带毫秒精度的timestamp - 尝试
localStorage.setItem('lock', JSON.stringify({id: windowId, ts: timestamp}))，然后立即读回比对——因为setItem不返回是否成功，必须二次验证 - 若读出的
ts与自己写入的一致，且距今 - 释放锁时清空
lock，并用bc.postMessage({type: 'lock_released'})广播
监听 BroadcastChannel 时如何避免重复响应或竞态
收到 lock_released 消息不代表你能立刻上锁——可能已有另一个窗口抢先写入了新锁。所以监听逻辑必须配合本地状态轮询或重试机制，不能“一触即发”。
- 收到广播后，不要马上调用锁申请函数，而是触发一次
checkAndAcquireLock()，该函数内部会重新读localStorage并判断 - 用
setTimeout加 10–30ms 延迟再检查，避开多个窗口几乎同时收到广播后的集中抢锁 - 监听器注册前加防重：检查
window.__bc_listener_registered标志位，避免同一页面多次绑定造成消息重复处理
Chrome 扩展 popup 和 content script 场景下的特殊限制
Popup 页面关闭后，其 BroadcastChannel 实例会自动关闭，但 localStorage 锁可能残留；content script 运行在独立上下文，无法直接访问 popup 的 window 或其 BroadcastChannel 实例。
- popup 关闭前务必显式调用
bc.close()并清除锁：localStorage.removeItem('lock') - content script 需通过
chrome.runtime.sendMessage中转锁请求，由 background script 统一管理localStorage和广播分发 - background script 是唯一可信的锁仲裁点，所有窗口都只向它发
acquire/release请求，它再用BroadcastChannel同步状态
