直接看现象：你改完数据点保存，页面刷新后发现值变回了旧的；或者两个标签页同时编辑同一份配置，关掉一个再切回来，发现刚输的内容没了——这不是 bug，是 localstorage 本身的并发裸奔现场。
一眼识别覆盖发生的典型信号
不用翻控制台、不靠猜，以下行为组合出现，基本可判定已中招：
- 数据“回滚”但没报错：比如主题从 dark 切成 light 后又自动跳回 dark，localStorage 里查到的值确实是 light，但页面读出来却是旧值
- 多个标签页操作后，最终结果不符合任一操作逻辑：A 标签页把购物车数量 +1（3→4），B 标签页同时 -1（3→2），结果最后是 2 或 4，而不是预期的 3（说明中间某次读取用了过期快照）
- localStorage 值频繁“跳变”，且变化时间与用户操作不严格对应：用 DevTools 的 Application → Storage → Local Storage 手动刷新几次，发现同一 key 的 value 在几秒内来回切换
- 写入前读取的值，和写入后立即读取的值不一致：在 setItem 前 console.log(localStorage.getItem('x'))，再在 setItem 后立刻再 log 一次，发现两次输出不同（说明别的标签页在中间插了一脚）
用 storage 事件做“案发现场还原”
localStorage 本身不记日志，但浏览器会在其他同源标签页调用 setItem 时，向当前页触发 storage 事件——这是唯一能“看到别人写了什么”的窗口。
加一段轻量监听，就能捕获覆盖瞬间：
（复制进控制台即可运行）window.addEventListener('storage', (e) => {
if (e.key === 'cart' || e.key === 'user-preferences') {
console.warn('[STORAGE CONFLICT]', '检测到其他标签页修改了', e.key,
'旧值:', e.oldValue, '新值:', e.newValue,
'来源页:', e.url || '未知');
}
});
如果这个监听频繁打印、且 old/new 值明显是不同用户的意图（比如一个设 theme=dark，另一个设 theme=light），那就是竞争正在发生。
检查代码里是否埋着高危模式
不是所有 localStorage 写入都会出事，但以下写法等于在雷区跳舞：
-
“读-改-写”三步拆开写：
let data = JSON.parse(localStorage.getItem('x')); data.a++; localStorage.setItem('x', JSON.stringify(data));—— 两行之间就是竞态窗口 -
多个组件/模块共用同一无前缀 key：比如 user.js 和 cart.js 都直接用
setItem('config', ...)，谁最后写谁赢 - 写入未加任何防抖或节流：输入框每打一个字就存一次 localStorage，500ms 内触发 10 次写入，大概率后写的覆盖前写的
-
锁名静态、粒度太粗：用了
navigator.locks.request('storage-lock', ...)却没意识到这会把整个应用的 localStorage 写都串行化，反而暴露了底层不兼容事实
验证是否真被覆盖：用时间戳打标记
临时加一行诊断代码，给每次写入带上“出生证明”：
function safeSetWithStamp(key, value) {
const stamped = {
value,
ts: Date.now(),
pageId: `tab_${Date.now()}_${Math.random().toString(36).substr(2,5)}`
};
localStorage.setItem(key, JSON.stringify(stamped));
}
之后在控制台执行：JSON.parse(localStorage.getItem('your-key'))。如果看到多个写入的 ts 差距很小（pageId 不同，那就是多标签页在抢写——血案实锤。
