# 开始下一个 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 替代品。

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

- HTTP / REST；
- GraphQL；
- gRPC；
- WebSocket；
- SSE；
- OAuth 等认证流程；
- Kubernetes 集群自动端口转发；
- 项目变量与模板化数据访问。

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

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

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

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

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

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

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

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

- **探索陌生 JSON 结构**：比如 API 返回、日志、配置文件、云服务响应；
- **学习 jq 表达式**：不用每次在命令行里反复执行和修改。

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

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

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

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

- URL 编码 / 解码；
- Base64 编码 / 解码；
- HTML 转义 / 反转义；
- JSON 字符串转义；
- Hex 和 RGB 颜色格式转换；
- Markdown 转 HTML；
- YAML 和 JSON 互转；
- camelCase、PascalCase、kebab-case、snake_case 之间转换。

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

文章给出的例子是：

```bash
echo 'camelCase' | sttr kebab
```

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

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

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

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

- **jnv：优先级高。** 用它辅助写 jq、探索 JSON，基本不改变现有流程，试用风险低。
- **sttr：优先级高。** 用它替代零散字符串转换命令，适合作为个人工具，试用风险低。
- **Resterm：优先级中。** 用它复刻一组常用 API 请求，但需要额外验证团队协作和迁移成本。

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

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

## 我的建议

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

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

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

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

## 参考链接

- 原文：https://www.howtogeek.com/every-web-developer-needs-to-try-these-open-source-tuis-before-starting-their-next-project/
- Resterm：https://github.com/unkn0wn-root/resterm
- jnv：https://github.com/ynqa/jnv
- sttr：https://github.com/abhimanyu003/sttr