Hoppscotch：浏览器里的 API 客户端，能替代 Postman 吗

它解决什么问题，给谁用

Hoppscotch 定位是 Postman 和 Insomnia 的开源替代品。它解决的问题很具体：API 开发者需要快速构造请求、查看响应、调试 WebSocket 或 GraphQL，但不想被一个重量级桌面应用拖慢。它的核心场景在浏览器里，通过 PWA 安装后可以离线使用，也支持桌面端和 CLI。适合那些日常调试 REST API、偶尔测试实时协议的开发者。它不追求取代整个 API 生命周期，而是聚焦在请求发送和响应查看这一高频动作上。

请求机制：从方法到响应，中间发生了什么

Hoppscotch 的请求流程在 README 里描述得很直白：选方法，填 URL，发送。它支持标准 HTTP 方法，包括 GET、POST、PUT、PATCH、DELETE、HEAD、CONNECT、OPTIONS、TRACE，还允许自定义方法，比如某些 API 用的 LIST。这背后是浏览器环境，所以它直接受 CORS 限制。为了绕过这个问题，它提供了代理模式，可以隐藏 IP、修复 CORS 问题、访问非 HTTPS 端点。官方代理服务器由 Hoppscotch 托管，你也可以用自己的代理，相关代码在 proxyscotch 仓库。这意味着请求不一定直达目标服务器，可能经过第三方，这是隐私上需要权衡的点。

不止 REST：WebSocket、MQTT 和 GraphQL 的覆盖

Hoppscotch 不只是 REST 客户端。它支持 WebSocket 全双工通信、Server-Sent Events 流式接收、Socket.IO 收发数据、MQTT 订阅和发布，以及 GraphQL 查询。GraphQL 支持设置端点后获取 schema，多列文档，自定义请求头，查询 schema 并获取响应。这些协议在 Postman 里要么需要额外插件，要么支持不完整。Hoppscotch 把它们整合在一个界面里，对做实时应用或物联网开发的工程师有实际价值。但注意，这些功能的具体实现细节在 README 里没有展开，比如 MQTT 的 broker 连接配置，需要参考文档才能确认。

部署方式：从云端到自托管，命令和配置

Hoppscotch 提供多种部署形态。最简单的是直接用官网的云服务，或者作为 PWA 安装到本地。对于需要数据控制权的团队，可以自托管。README 没有给出具体的 docker 命令，但仓库是标准的 TypeScript 项目，默认分支是 main，最新版本是 2026.8.0。自托管通常涉及构建前端和后端服务，配置数据库和认证。具体步骤在官方文档里，但这里没有提供。如果你不想依赖公共代理，需要自己部署 proxyscotch，这是一个独立的 GitHub 仓库。部署成本不算低，需要 Node.js 环境和一定的运维能力。

协作与同步：云同步是亮点，也是依赖

Hoppscotch 的团队功能包括创建无限团队、共享集合、角色权限控制、云同步和多设备支持。它还支持工作区，区分个人和团队环境。登录方式有 GitHub、Google、Microsoft、Email，以及企业版的 SSO。同步的数据包括工作区、历史、集合、环境和设置。这听起来方便，但意味着你的数据默认存储在 Hoppscotch 的服务器上，除非你自托管。对于注重数据隐私的团队，这是一个需要评估的点。另外，同步依赖网络，离线时只能访问本地缓存，这限制了它的可靠性。

脚本与测试：预请求和响应断言的实际边界

Hoppscotch 支持预请求脚本，可以在发送请求前执行 JavaScript，比如设置环境变量、添加时间戳、生成随机字符串。响应后测试也支持，可以检查状态码、过滤响应头、解析响应数据。这些功能覆盖了基础场景，但 README 里没有提到像 Postman 那样的集合运行器或数据驱动测试。也就是说，如果你需要复杂的测试流水线，比如多阶段请求或依赖链，Hoppscotch 目前可能不够。它的脚本是每个请求独立的，没有提到全局脚本或跨请求共享状态。这是一个明显的功能边界。

与 Postman 的实质差异：轻量 vs 重量，浏览器 vs 桌面

Postman 是桌面应用，依赖 Electron，内存占用高，启动慢。Hoppscotch 是浏览器优先，PWA 安装后占用低，启动快。这是最核心的差异。Postman 的强项是团队协作、API 文档生成、环境管理和测试自动化，这些 Hoppscotch 有部分覆盖，但深度不同。比如 Postman 的集合运行器可以按顺序执行请求并生成报告，Hoppscotch 没有提到类似功能。另一方，Hoppscotch 的代理模式解决了浏览器 CORS 问题，而 Postman 因为是桌面应用，没有这个限制。所以选择不是简单的替代，而是看你的工作流更依赖哪一端。

维护与许可证：MIT 下的风险与机会

Hoppscotch 使用 MIT 许可证，这对商业使用友好，你可以自由修改和分发。项目最近更新频繁，版本号从 2026.6.1 到 2026.8.0，说明维护活跃。但活跃也意味着 API 可能变化，升级时需要注意兼容性。自托管的话，你需要跟进版本，因为安全修复和功能更新都依赖你主动升级。官方代理服务器是集中式的，如果它出现故障或政策变化，依赖它的用户会受影响。没有看到长期支持版本的承诺，所以对于生产环境，你需要自己测试每个版本的稳定性。

编辑结论

Hoppscotch 适合那些重视轻量、愿意在浏览器里完成大部分 API 调试的开发者，尤其是个人开发者和小团队。它不适合需要强离线能力、复杂团队权限或深度企业集成的场景。如果你打算采用，先确认三点：一是你的 API 是否允许流量经过 Hoppscotch 的公共代理，或者你是否有能力自建 proxyscotch；二是团队协作是否依赖云端同步，这需要你接受 Hoppscotch 的认证体系；三是你的工作流是否依赖 Postman 的测试脚本和集合运行器，Hoppscotch 的 post-request tests 目前只覆盖基础断言。最终判断：如果你能接受浏览器作为主战场，Hoppscotch 是一个值得替换 Postman 的轻量选项，但如果你需要的是完整的 API 生命周期管理，它还不是。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes