这个免费工具，让API密钥不离开浏览器

你是否也受够了在终端和浏览器之间反复切换窗口——复制粘贴命令、手动格式化 JSON、盯着杂乱响应头一行行寻找线索，只为调试一个简单的 API？试过那些号称“在线 HTTP 客户端”的工具，却总得提心吊胆：我输入的密钥、令牌和参数，会不会先被它们的后端服务器暂存甚至记录？

一位同样头疼的开发者兼安全研究者，干脆自己写了一个完全跑在浏览器里的替代方案：curl.codewithneo.com。它的核心逻辑简单到近乎倔强：所有请求一律从你当前的浏览器直接发出，绝不经过任何中间服务器。这意味着，在它这里，根本没有一个所谓“后端”能接触到你的敏感数据。

开发者最初的目标很明确：只想更快地测试 API、格式化载荷、检查响应头，而不必在每一次小调整时都弄脏终端的历史记录。他没有选择给现有工具写补丁或者凑合用，而是从头构建了一个轻量、干净的界面，让你可以直接贴入 cURL 命令，或者动几下鼠标就构建好请求。整个过程没有跳转、没有注册弹窗，甚至不需要你关掉当前浏览器标签页。

围绕“完全在客户端执行”这个设计，安全性被推到台前。常见的在线 HTTP 测试工具大多会把你的请求转发到自己的后端，表面上是替你处理跨域或者提供历史记录，可实际上，API 密钥、Bearer Token、端点路径等全部暴露给了那台第三方服务器。一旦服务器被攻击，或者日志被滥用，这些凭据就可能在毫不知情的情况下从“只属于你”变成“公开的秘密”。而在这个工具里，所有数据从输入框直达目标 API，浏览器自身的安全边界就是唯一关隘，数据流不会绕道任何你无法控制的机器。如果你本身就在浏览器里跑一个管理面板或测试用例，甚至无需离开页面去验证某个接口，安全性丝毫不会打折。

另一个吸引导向是“免费”的彻底性。这里没有基础功能免费、高级方法付费的套路，也没有要求你创建账号才能解锁 POST 或 PUT 请求；甚至不需要输入邮箱来“激活”。开发者把它当作一个完全开放的调试器：任何人都能直接打开网址，立刻开始工作，用完即走。对自由职业者、安全研究员、参加黑客松的学生来说，这种零门槛意味着可以把省下来的时间真正花在请求本身上，而不是研究各种套餐、担心月底信用额度。

界面设计也刻意压低了存在感。整个页面没有花哨的动画，没有侧边栏推广，只有几个关键区域：一处粘贴 cURL 命令，一处显示结构化响应，一处让你逐条修改请求头和请求体。这种极简的布局使得从打开页面到发出第一个请求，几乎不需要任何学习成本。如果你已经熟记 cURL 参数，直接复制粘贴命令就行；如果更喜欢手动构建，表单会立刻响应字段的增删，JSON 负载也会实时进行格式化，不必再去别的网站反复美化。对于频繁测试、需要快速查看响应头信息的场景，这种即时性本身就节约了大量无意义的操作和等待。

那么，拥有本地终端里的 cURL，为什么还要用到浏览器版？开发者给出的几个理由，恰好戳中日常开发中的微小痛点。首先，浏览器提供了一个自然的可视化空间：响应头会被整理成清晰的键值列表，巨大的嵌套 JSON 会被自动着色并折叠，再也不用对着终端里堆叠的文本手动格式化或一行行滚动。其次，每次你想调整一个请求参数，比如加一个自定义请求头或修改请求体的某个字段，浏览器版可以保留当前会话的上下文，避免在终端历史中反复调出、修改、重新执行命令，从而降低因手滑而覆盖正确参数的风险。第三，在某些受限制的环境里，比如 chromebook 或无法安装本地工具的设备上，一个完全依赖 Web 平台的 HTTP 客户端就是最直接的帮手。

当然，正因为所有请求都从浏览器端发出，跨域资源共享（CORS）策略可能会在访问一些未设置开放策略的 API 时产生限制。开发者自己也在请求反馈时特别提到了这一点，希望用户将遇到的 CORS 问题或者希望新增的功能提交过来。这种坦诚反而体现出一个特点：它不试图宣称万能，而是把已知的边界提前摊开，由使用者根据自身场景决定是否适用。如果你本身就是前端工程师，理解 CORS 如何工作并能够通过浏览器插件或服务端配置来配合，这样的工具反而比固定后端的方案更灵活。

目前，这个工具没有任何付费计划，也没有引入广告的迹象。它更像是一个典型的“开发者为自己做轮子，顺便分享出来”的产物：因为受不了现有的方案，所以动手解决，并愿意听取社区的改进建议。对于关注数据流向、讨厌无谓注册、想在几秒钟内完成一次干净 HTTP 测试的人来说，关闭那些总想保存你凭据的在线客户端，转而在浏览器里直接执行所有请求，或许就是一种舒服得多的日常选择。