做前端久了，你可能会有一种感觉：我们每天都在和 HTTP 打交道，发请求、接数据、渲染页面，但在这个过程中，我们其实挺被动的。
前端似乎从来没有真正“控制”过 HTTP。
大家肯定都经历过这种场景：
为了验证一个 Network 层面的边缘情况，我们不得不去弄脏业务代码，或者去麻烦后端配合。
这事儿其实挺别扭的。明明是网络层面的状态，为什么要侵入到 View 层甚至 Logic 层去模拟？仅仅因为 HTTP 响应一旦发出来，我们就只能看着，改不了。
Chrome DevTools 很好，但还不够
我们都离不开 Network 面板。它很强大，能把请求的所有细节展示得清清楚楚。
但它的局限性也很明显：它只能“读”，不能“写”。
它像个监控摄像头，让你看到了所有发生的事情，但当你想介入——比如想把那个返回 200 的请求临时改成 401 看看鉴权逻辑对不对时——它就无能为力了。
于是，我搞了一个更直接的路子
为什么不能把对 HTTP 的控制权，直接收回到浏览器里呢？
不需要改代码，不需要起本地 Node 服务，也不需要复杂的代理工具。就在浏览器里，拦截住那个请求，篡改它的响应，然后再放行给页面。
基于这个想法，我写了个小工具：Pocket Mocker。
它的逻辑非常简单粗暴，就是为了解决前端不能直接控制http的问题：
- 它接管了请求： 在浏览器收到后端响应后，页面代码拿到数据前。
- 它允许你篡改： 你可以随意修改
status code、headers，或者直接重写response body。 - 它完全无感： 对你的业务代码来说，这一切就像是真的从服务器返回的一样。
这不是一个重型 Mock 方案，而是一把手术刀
我没打算用它替代 Mock Server，它更像是一个调试阶段的临时“手术刀” 。
- 突然想测下接口超时或报错的 UI 表现？拦一下，改个状态码，刷新看看。
- 线上环境出了个诡异的数据 bug？在本地把那个特定的 Response Body 贴进去，精准复现。
- 测完了一刷新，一切还原，不对项目代码造成任何污染。
这就是我想要的：即用即走，不留痕迹。
写在最后
其实做这个工具的初衷，就是觉得前端不应该只是 HTTP 的“接收端”。
当我们能从浏览器层面直接控制 HTTP 的行为时，很多原本复杂的联调沟通和代码侵入，其实都是可以避免的。
如果你也受够了在代码里写 // TODO: remove this mock data，不妨试试这个路子。
项目在这个仓库： 👉 GitHub: pocket-mocker
