开始下一个 Web 项目前，可以先试试这 3 个开源 TUI 工具

本文整理自 How-To Geek 文章 *Every web developer needs to try these 3 open-source TUIs before starting their next project*：https://www.howtogeek.com/every-web-developer-needs-to-try-these-open-source-tuis-before-starting-their-next-project/

很多 Web 开发者已经习惯把终端当作主工作台：拉代码、跑测试、看日志、查接口、处理配置文件。问题是，一旦遇到 API 调试、JSON 查询、字符串格式转换这些高频小任务，大家往往又会切回浏览器、桌面应用，或者临时拼一串容易出错的 Shell 命令。

这篇文章推荐的 3 个开源 TUI（Terminal User Interface）工具，价值不在于“彻底替代所有 GUI 工具”，而是把几个常见开发动作留在终端里完成：

  1. 用 Resterm 调试 API；
  2. 用 jnv 交互式探索 JSON 和 jq 查询；
  3. 用 sttr 处理字符串格式转换。

如果你的开发环境经常在本地终端、远程服务器、容器或 SSH 会话之间切换，这类工具尤其值得试一轮。

1. Resterm：终端里的 API 客户端

Resterm 可以理解为一个面向终端用户的 API 调试工具，定位有点像 Postman 的 TUI 替代品。

它支持的协议和场景比较多：

文章中特别提到，Resterm 支持通过 .env 或 resterm.env.json 存储项目变量，并用类似 {{ foo.bar }} 的模板语法引用数据。它还有自己的脚本引擎 RestermScript，可以处理复杂的链式请求。

这意味着它不只是“在终端里发一个 HTTP 请求”，而是试图覆盖一部分 API 客户端常见工作流：认证、变量、请求链、不同协议、脚本化。

不过，Resterm 更适合先作为个人效率工具试用，而不是马上替代团队现有的 Postman 或 Insomnia。原因很简单：API 工具在团队里通常还承担集合共享、测试文档、协作评审、报告输出等职责，原文没有给出这些维度的充分对比。

更稳妥的试法是：先选一个低风险内部服务，用 Resterm 复刻一组常用请求，看看它在认证、变量管理、请求链维护上的体验是否真的比现有工具更顺。

2. jnv：用即时反馈学习和调试 jq

jq 很强，但也很容易让人“每次都要重新查语法”。尤其面对陌生 JSON 时，常见流程是：先猜一个过滤表达式，运行，报错或结果不对，再改，再运行。

jnv 的价值就在这里：它提供一个交互式终端界面，让你一边输入 jq 查询，一边看到 JSON 过滤结果。

这类即时反馈对两个场景很有用：

原文作者说 jnv 让学习 jq 的速度提升了 10 倍，这个数字更像个人感受，不应当当作严格 benchmark。但“缩短反馈循环”本身是可信的：当工具能实时显示过滤结果，用户自然更容易建立 JSON 结构和 jq 表达式之间的对应关系。

对于经常处理 JSON 的开发者，jnv 可能是这 3 个工具里最容易低成本试用的一个。它不会替代 jq，而是让你更快写出正确的 jq。

3. sttr：把常见字符串转换收进一个工具

开发中有很多小而烦的字符串处理任务：

这些任务都不大，但如果每次都临时拼命令、打开网页工具，成本会累积。sttr 的定位就是把这些转换集中到一个 CLI/TUI 工具里。

文章给出的例子是：

echo 'camelCase' | sttr kebab

当你只通过管道传入文本但不指定转换目标时，sttr 也可以进入交互式 TUI，让你选择要执行的转换，并支持通过 / 搜索过滤。

它的意义不是技术上多复杂，而是减少“为了一个格式转换临时拼错命令”的概率。对重度终端用户来说，这类工具很容易变成肌肉记忆。

怎么判断这 3 个工具值不值得用

可以按“替换成本”从低到高来试：

如果只是个人开发效率提升，jnv 和 sttr 的试错成本最低：装上，用几次，不合适就不用。

Resterm 的评估要更谨慎。API 调试工具一旦进入团队流程，涉及的不只是“能不能发请求”，还包括集合管理、权限、共享、文档、CI 集成、团队成员学习成本等。它适合先在个人或小范围内部服务上试点。

我的建议

如果你经常在终端里处理 Web 开发任务，可以这样开始：

  1. 先试 jnv：找一个真实 API 响应或配置 JSON，用它写出 2–3 个 jq 查询；
  2. 再试 sttr：把 Base64、URL 编解码、大小写转换这些日常小动作交给它；
  3. 最后再评估 Resterm：只在一个低风险项目里复刻现有 API 调试流程，不急着替代团队工具。

这 3 个工具共同体现了一个思路：不是所有开发辅助工具都必须是大型平台。有些高频、局部、反馈明确的小任务，放进终端里的轻量 TUI 反而更顺手。

但也要保持边界感：终端效率工具适合缩短个人反馈循环，不等于天然适合团队标准化流程。真正要纳入团队工具链时，仍然需要看协作、可维护性、权限、文档和长期支持。

参考链接