StackPrism 浏览器技术栈检测扩展架构解析：Manifest V3 Service Worker 低内存设计全解

StackPrism 是一款基于 Manifest V3 的浏览器技术栈检测扩展，支持 Chrome / Edge / Firefox，能从响应头、页面 DOM、资源 URL、动态加载等多个维度识别网站使用的技术。它没有常驻后台进程，全部依赖 Service Worker 事件驱动 + 会话级存储的低内存设计，非常适合想在浏览器扩展里做"持续监测类"功能的开发者参考。

一、为什么技术栈检测工具适合 Service Worker

传统扩展（Manifest V2）可以挂一个常驻的 background page，随开随用、内存一直占着。MV3 取消了常驻后台页，改用 Service Worker：有事件就唤醒，没事件就休眠，空闲约 30 秒后浏览器直接回收进程。

对技术栈检测这类"页面加载时抓响应头、用户点刷新时注入脚本"的场景，这种模式天然契合：

• 📡 页面加载 →webRequest事件唤醒 Worker，记录响应头
• 🖱️ 用户点弹窗 → 消息事件唤醒 Worker，执行注入检测
• 😴 无事发生 → Worker 休眠，内存占用归零

入口文件 src/manifest.config.ts 中只有一行关键配置：service_worker: 'src/background/index.ts'且声明type: 'module'，这是一个ESM module worker，可以用标准 ES 模块语法拆分后台代码。

二、四路执行环境：各司其职

StackPrism 把浏览器扩展的四种执行环境全部用上了，职责划分非常清晰（详见 docs/dev/architecture.md）：

其中 Injected Script 是"用完即弃"的：它被独立编译成 IIFE 单文件（见 vite.injected.config.ts），通过chrome.scripting.executeScript({ files })注入、返回结果后不留驻，不会占用页面内存。

💡 这里有个 MV3 ESM 的经典坑：ESM 模块不能像以前那样靠Function.prototype.toString序列化后注入页面。StackPrism 的解法是"两次 RPC"——先func把规则写入window.__SP_RULES__，再files注入 IIFE 读取规则并返回结果，实现见 src/background/detection.ts。

三、低内存设计核心 1：状态全部外置到 storage.session

Service Worker 随时可能被杀，所以任何重要状态都不能只放在内存里。StackPrism 的做法是把每个标签页的检测结果全部写入chrome.storage.session：

• tab:{tabId}—— 该标签页的完整检测数据（响应头 / 页面 / 动态快照）
• popup:{tabId}—— 弹窗展示用的轻量缓存

读写集中在 src/background/tab-store.ts，Worker 被杀后重启，直接从 storage 恢复状态，不依赖 Worker 内存。

还有一个贴心的兼容层 src/utils/browser-compat.ts：个别环境不支持storage.session时自动降级到storage.local，逻辑不变。

四、低内存设计核心 2：大文件懒加载 + 编译缓存

检测规则是"数据"而非"代码"，全部放在 public/rules/ 下，按类别拆成 50+ 个 JSON，由 public/rules/index.json 索引：

1. 懒加载：Worker 首次用到才fetch，并且用一个 Promise 缓存（src/background/detector-settings.ts），加载一次、进程内复用。524 KB 的 public/tech-links.json 同理。
2. 不内联进 bundle：文档 docs/dev/architecture.md 特别强调——不要用import rules from '...'导入大 JSON，否则会被打进 bundle，Service Worker 冷启动会明显变慢。
3. 构建期预编译：vite.config.ts 中的precompileRulesPlugin在构建时给每条规则注入__hints（必需字面量）和__keywordCombined（合并正则），运行时 src/background/rule-matcher.ts 先做字面量预筛，只评估可能命中的候选规则；正则编译结果用 WeakMap 缓存，每条规则只编译一次。

五、低内存设计核心 3：节流、防抖与按需清理

后台的 src/background/index.ts 是一组事件监听器，围绕它做了多层"削峰"：

• ⏱️检测节流：同一标签页 30 秒内最多跑一次主动检测（src/background/detection.ts）
• 🌊快照防抖：content script 约 900ms 最多上报一次 DOM 变化，Worker 端再防抖 800ms 才匹配规则
• 🔒写锁串行：多个事件可能同时修改同一标签页数据，src/background/tab-write-lock.ts 保证 read-modify-write 不互相覆盖
• 🧹标签关闭即清理：chrome.tabs.onRemoved触发后清掉该标签的定时器、会话数据、徽标（src/background/index.ts），不留"僵尸状态"
• 🏷️徽标去重：徽标内容没变化就不调用 action API，避免无谓的工具栏重绘（src/background/tab-store.ts）

六、8 种消息：跨脚本通信的"单一入口"

Worker 与弹窗 / content / injected 之间只有 8 种消息，全部在 src/types/messages.ts 用 discriminated union 定义类型，运行时由 src/background/message-router.ts 统一路由：

完整表格见 docs/dev/architecture.md。

七、关键源码导读：三分钟找到每个设计点

• 扩展声明（MV3 配置、权限、content script）：src/manifest.config.ts
• 事件监听总入口：src/background/index.ts
• 会话缓存读写：src/background/tab-store.ts
• 规则加载与合并：src/background/rule-loader.ts
• 规则匹配加速：src/background/rule-matcher.ts
• 检测调度与节流：src/background/detection.ts
• 消息类型定义：src/types/messages.ts
• 官方架构文档：docs/dev/architecture.md、docs/dev/detection-flow.md

小结

StackPrism 的"低内存"不是某一行代码的功劳，而是一套组合拳：

1. 事件驱动——MV3 Service Worker 干完就睡，无常驻进程；
2. 状态外置——标签页数据全放storage.session，Worker 重启无损恢复；
3. 数据懒加载——规则 JSON 按需 fetch + Promise 缓存，冷启动轻；
4. 多层削峰——节流、防抖、写锁、关闭清理，把峰值压力摊平。

如果你想给自己的浏览器扩展做类似"持续监测"功能，这套"ESM module worker + 会话存储 + 懒加载数据 + 节流防抖"的模式几乎可以直接照搬。