xh 实测：比 curl 多 38 毫秒换可读性｜实测库

xh 是一个命令行 HTTP 客户端，主程序 10654208 字节。写法比 curl 短：xh GET 地址，响应头和 JSON 正文自动分色并缩进。

它解决的问题是「curl 的输出没法直接看」。curl 拿到一段 JSON 原样吐出来，要看结构得再接 jq；xh 一次就把头、状态行和缩进后的正文都排好。

这次在本地起了一个 HTTP 服务，用同一份 15691 字节的 JSON 分别跑 xh 和 curl，量了三次耗时与输出体积，还撞到一个默认方法的坑。

解压 10654208 字节的单文件

官方 zip 4367226 字节，解开是主程序加几个补全脚本，没有配置文件也没有主题目录。

版本行里带 TLS 实现

# 三次耗时 322 / 198 / 191 毫秒
xh --version
xh 0.26.3
+native-tls +rustls

两套 TLS 都编进去了。访问老服务器遇到证书链问题，可以换另一套实现试，不用重装。

没有配置文件

10654208 字节里不带默认配置。想固定默认头或者别名，得自己建 config.json 放到用户目录，程序启动时自己找。

同一个请求，xh 与 curl 对照

本地服务返回 15691 字节的 JSON，三次跑下来 xh 是 219 / 167 / 166 毫秒，curl 是 208 / 127 / 129 毫秒。两者输出字节完全一样，都是 15691。

多出来的时间在解析与着色判断

xh 要判断响应的内容类型、决定要不要按 JSON 缩进，还要算颜色。15691 字节的正文摊下来多 38 毫秒，请求本身两边一样快。

管道里两边都不上色

输出重定向到文件时，xh 自动关掉颜色，字节数回到 15691，和 curl 完全一致。想留颜色得显式加 --pretty=all 之类参数。

屏幕上多出来的东西

在终端里跑，第一行是状态行 HTTP/1.0 200 OK，接着五行响应头，然后是缩进过的 JSON。截图那次正文只有三行，整块都在一屏里。

状态行单独一行很实用

curl 默认不打印状态行，要加 -i。xh 默认就打，排查 502 和 404 时第一眼就能分辨，不用改命令。

响应头按值类型分色

头名一种颜色，数值另一种。扫一眼就能找到 Content-Type 和 Content-Length，比在纯文本里找冒号快。

装之前先确认三件事

解压即用，不写注册表。要确认的是默认方法和编码，这两样直接影响请求发出去对不对。

参数顺序是「方法、地址」

xh GET 地址 或者 xh POST 地址 键=值。方法名大写在前面，地址紧跟，后面才是表单或者 JSON 字段。

它不读 curl 的配置

已有 .curlrc 或环境变量代理设置的人要注意，xh 认的是自己的 config.json 和 HTTP_PROXY 这类标准变量，两套配置不会互相继承。

三个真会踩的地方

不给方法时发的是 POST

把标准输入指向空设备再跑 xh 地址，它当成有请求体，发出的是 POST。本地那个只认 GET 的服务器直接回 501，输出 357 字节错误页，退出码 5。加显式 GET 就正常，三次都在 167 毫秒上下。

输出进文件后看不到颜色

重定向到文件时颜色自动关闭，这是对的。但有人为了留颜色加 --color=always，结果文件里全是转义序列，grep 出来的结果没法读。

中文要加 charset

服务端不声明字符集时，xh 按 UTF-8 处理。返回 GBK 的接口会乱码，得加 --response-charset=gbk 手动指定。

什么场景值得上

调试接口时最合适。一条命令看到状态码、响应头和结构化的正文，167 毫秒出结果，比开 Postman 点半天快。

反过来，只偶尔下载一个文件的人用不上。Windows 自带的 curl 已经够，多装 10654208 字节换来的是可读性，不是能力。