restoreExtensionTabs vs ext-context-guard 双 reload¶
来源¶
v0.10.47 第三轮独立 agent 跨模块发现。
现象¶
扩展 update / reload 时，两套机制同时触发 tab reload：
| 机制 | 位置 | 触发 |
|---|---|---|
| restoreExtensionTabs | background/index.ts:328 (v0.10.34 加) |
onInstalled('update') → 立即 tabs.reload |
| ext-context-guard | ext-context-guard.ts:71 (v0.10.29 加) |
5s 周期检测 invalidated → 1.5s 延迟后 location.reload |
链条： 1. T=0 用户 reload 扩展 2. T+10ms SW 重启 → onInstalled('update') 触发 restoreExtensionTabs → tabs.reload(tabId) 3. T+? tab 开始 reload，main.html 重新加载 4. T+5s（最坏情况）旧 tab 的 ext-context-guard 5s 周期检测仍跑（已经 reload 过了）→ 检测到新 context valid → 不触发
实际上 v0.10.34 的主动 reload 让旧 context 立即重新加载，新 context valid，guard 检测不到 invalidated → 不会双 reload ✅
重新评估¶
agent 报告说"两次 reload"，但实际上： - v0.10.34 SW reload 让 tab 立即拿到新 context（毫秒级） - guard 5s 周期检测下次跑时新 context 已 valid → 不触发
所以这其实不是 bug。可能 agent 看代码没看到 v0.10.34 reload 的即时效果。
但有一个小风险¶
如果 v0.10.34 reload 失败（chrome.tabs.reload 抛错被 try-catch 吞），那 guard 5s 后会兜底 reload。这是设计 — 双轨保险。
处置¶
结论：不是 bug，是双轨保险设计。
但如果未来想优化"在 v0.10.34 主动 reload 成功后让 guard 跳过"，可以加 storage flag：
// background restoreExtensionTabs 后
await storage.setItem('local:lastForceReload', Date.now());
// guard 检测前
const last = await storage.getItem('local:lastForceReload');
if (last && Date.now() - last < 10000) return; // 10s 内有主动 reload，跳过
但当前没必要 — 双 reload 概率极低，影响小。
优先级：极低¶
仅在未来发现"用户报告频繁意外 reload"时再处理。
2026-05-28 评估结论：discarded¶
判定：agent 误报，不是 bug。
理由：
- v0.10.34 SW 重启时 restoreExtensionTabs 主动 tabs.reload(tabId) 是毫秒级
- ext-context-guard 5s 周期检测下次跑时，新 context 已 valid → 不触发兜底 reload
- 即使主动 reload 偶尔失败被 try-catch 吞，guard 5s 兜底 — 这是双轨保险设计，不是浪费
未来若想严格"互斥"（v0.10.34 reload 成功后让 guard 跳过），可加 storage flag。但当前无必要：双 reload 概率极低，影响小。