基于浏览器扩展 API Mock 工具开发探索

原创于 2025-09-23 16:16:42 发布 · 1.4k 阅读

29 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #后端

在复杂业务场景中，往往需要Mock的接口都比较多。如果能监听页面所有请求，然后提供通过选中某个历史请求即可Mock接口的方式，就能快速实现接口的Mock。

一、前言

二、浏览器插件介绍

1. 什么是浏览器插件？

2. Manifest V3 架构

3. 核心配置差异示例

三、Mock 插件实现的基本原理

1. 请求拦截的核心原理

2. 脚本注入

四、整体实现架构与流程

1. 项目结构设计

2. 相关功能介绍

3. 整体流程

五、总结与收获

六、未来展望

一、前言

在日常开发过程中，偶尔会遇到后端接口未完成或者某个环境出现问题需要根据接口返回来复现等等场景。刚好最近在学习浏览器插件的相关知识，并在此背景下开发了一款基于浏览器插件的 Mock 工具。该工具专注于 API 请求拦截和数据模拟，旨在帮助开发者提升开发效率，能够解决一些问题。

二、浏览器插件介绍

什么是浏览器插件

浏览器插件（Extensions 或 Add-ons）是一类运行于浏览器进程中的轻量级功能增强模块，其核心价值在于通过标准化接口实现对浏览器内核能力的深度整合与定制。根据 Mozilla 开发者文档定义，插件本质上是“能够修改和增强浏览器能力的应用程序”，Firefox、Chrome 等主流浏览器均采用 WebExtensions API 这一跨浏览器技术构建插件生态。与网页应用（Web App）需依赖浏览器标签页运行、原生应用（Native App）需独立安装的特性不同，插件以轻量化部署为显著特征——无需复杂设置即可直接在浏览器环境内运行，同时具备标签控制、网络请求拦截、本地存储访问等网页应用无法实现的底层能力。

Manifest V3 架构

Manifest V3 对浏览器插件的底层架构进行了颠覆性重构，主要体现在背景执行机制、网络请求控制和代码安全模型三个核心维度。以下从技术实现与设计动机角度进行全面对比：

关键架构变革：V3 采用"静态声明+内核级处理"模式替代 V2 的"动态脚本+插件自主控制"模式，通过浏览器内核直接介入关键流程（如网络拦截），在性能与安全性之间取得平衡。

核心配置差异示例

背景执行模块配置

// V2 持久化背景页配置"
background": {
  "scripts": ["background.js"],  
  "persistent": true             
}


// V3 Service Worker 配置
"background": {
   "service_worker": "background.js",  
   "type": "module"                   
}

网络请求规则配置

V3 需在 Manifest 中声明 DNR 权限及规则文件：

// V3 declarativeNetRequest 配置
"permissions": ["declarativeNetRequest"],
"host_permissions": ["<all_urls>"],
"declarative_net_request": {
   "rule_resources": [
       {"id": "ruleset_1","enabled": true,"path": "rules.json"  }
    ]
}

三、Mock 插件实现的基本原理

请求拦截的核心原理

由于 Manifest V3 移除了webRequest API 的阻塞能力，declarativeNetRequest又无法重定向到自定义数据，于是方案上选择的是在页面上下文中重写原生 API，目前重写了fetch跟XMLHttpRequest。

// injected.js - 在页面环境中重写fetch
const originalFetch = window.fetch;
window.fetch = async function(url, options = {}) {
  // 1. 发送拦截请求到content script
  const response = await sendMockRequest(url, options);


  // 2. 如果有匹配的Mock规则，返回Mock数据
  if (response.shouldMock) {
    return new Response(
      JSON.stringify(response.mockData),
      {
        status: response.status,
        headers: response.headers
      }
    );
  }


  // 3. 否则执行原始请求
  return originalFetch.call(this, url, options);
};

脚本注入

通过多重注入策略 + 动态检测的方式实现，直接引入会触发 Content Security Policy 阻止内联脚本执行。

// content.js
async function injectScript() {
  // 策略1: 内联脚本注入
  try {
    await injectInlineScript();
    if (await checkScriptActivation()) return;
  } catch (e) {
    console.warn('内联注入失败:', e);
  }


  // 策略2: 外部脚本注入
  try {
    await injectExternalScript();
    if (await checkScriptActivation()) return;
  } catch (e) {
    console.warn('外部注入失败:', e);
  }


  // 策略3: 最简单注入方式
  await attemptSimpleInjection();
}

四、整体实现架构与流程

项目结构设计

chrome-mock/
├── build-script/          # rollup 进行构建
├── static/                # 静态文件引入，如mockjs
├── debug/                 # 本地调试相关的页面
├── manifest.json          # 插件配置
├── background.js          # 核心逻辑处理
├── content.js            # 脚本注入和消息中转
├── injected.js           # 请求拦截实现
├── options.html          # 管理界面
├── options.js            # 管理界面逻辑
├── options.css           # 管理界面样式
├── popup.html            # 弹窗界面
├── popup.js              # 弹窗逻辑
├── popup.css             # 弹窗样式
└── icons/                # 图标资源

整体流程

五、总结与收获

本次插件开发过程中，探索了浏览器扩展插件的能力，学习了 Manifest V3 的新知识，掌握了浏览器插件开发相关技术点。随之而来带来的思考便是在 AI 的浪潮下，浏览器插件是否能有更多的可能。

另外，本次很多功能点的实现也依赖了 Cursor，探索浏览器插件的同时也深入的学习了Cursor的应用，感受到了Cursor从 0 到 1 搭建过程中的速度和效率。但是在后续需要对功能点进行改造时，使用效率并不是高，如何建立规则和组织话术，让 AI 更加规范、高效地辅助开发是一个值得深思的问题，当然通过 rules 是能够解决大部分问题。