Proxy 劫持 API 详解与 mock 数据注入方法

本文深入解析了在前端开发中如何科学、稳定地实现 API 的 mock 数据注入，明确指出直接使用 Proxy 劫持 fetch 或 XMLHttpRequest 等原生 API 是不可行的（因其为只读内置函数），转而推荐通过重定义 fetch、补丁化 XMLHttpRequest.send 或封装统一请求函数等更可靠的方式，在请求前或响应解析后精准拦截并注入 mock；同时支持基于 URL、参数、登录态、环境变量等多维度的动态规则匹配，并兼容 Mock.js 语法以生成高仿真响应，还系统梳理了避坑要点——包括不代理宿主对象、规避 SDK 冲突、按环境可控开关及严格保持响应结构一致性，为开发者提供了一套可落地、易调试、高兼容的 mock 实践方案。

不能直接用 Proxy 劫持 API 返回结果来注入 mock 数据——因为 fetch、XMLHttpRequest 等原生方法本身不可代理，它们是只读、不可配置的内置函数，Proxy 只能作用于普通对象，而 window 或 globalThis 不符合要求。

真正可行的方式：在请求发出前/响应解析后做拦截

核心思路不是“劫持返回结果”，而是“在关键链路节点插入逻辑”，把 mock 注入时机前置或后置：

• 对 fetch 进行重定义：保存原始 fetch，用新函数包裹。在调用前判断当前 URL 是否命中 mock 规则；若命中，跳过真实网络请求，直接构造 Promise.resolve(mockData)
• 对 XMLHttpRequest.prototype.send 打补丁：监听 onload/onerror，在响应文本 ready 后、JSON.parse 前截获 responseText，根据 URL 和请求参数匹配 mock 规则，替换内容后再继续后续流程
• 不依赖 Proxy，改用函数重写 + 条件判断：比如封装统一请求函数 request()，内部先查 mock 表，命中则返回 mock，否则走真实 fetch —— 这比劫持更稳定、更可控、更易调试

如何实现业务规则驱动的动态 mock

mock 数据不能写死，要能响应不同参数、用户角色、环境变量等条件：

• 基于请求参数匹配规则：例如 /api/user?id=1001 返回管理员数据，id=1002 返回普通用户。可在 mock 配置中写成函数：{ "/api/user": (req) => req.url.includes("id=1001") ? { role: "admin" } : { role: "user" } }
• 结合本地状态做上下文感知：比如登录态存在时，/api/profile 返回带 email 的完整信息；未登录时只返回昵称和头像。可通过检查 localStorage 或全局 authStore 实现
• 支持 Mock.js 语法生成动态字段：在 mock 返回值中嵌入 @datetime、@guid、"status|1": ["success", "fail"] 等，让每次响应都略有差异，更贴近真实接口行为

避免踩坑的关键细节

落地时容易忽略但影响稳定性的问题：

• 不要试图代理 console、alert 等宿主对象：它们不是标准 JS 对象，Proxy 失效。需逐个重赋值方法（如 console.log = newLog），并确保调用原函数以保留开发者工具输出
• 绕过第三方 SDK 冲突：某些监控 SDK（如 Sentry、Bugsnag）也会 patch fetch，建议在它们初始化之后再执行你的 mock 注入逻辑，或用 try/catch 包裹防止报错中断
• 区分开发/测试环境启用：通过 URL 参数（如 ?mock=on）、localStorage 标志或环境变量控制开关，避免误带到生产环境
• 保持原始响应结构一致：即使 mock 数据是伪造的，也要确保 status、headers（尤其是 content-type）、响应体格式与真实接口完全一致，否则前端解析逻辑会出错

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Proxy 劫持 API 详解与 mock 数据注入方法》文章吧，也可关注golang学习网公众号了解相关技术文章。