今日三荐：命令行基准测试、HTTP 分段计时与终端窗口管理器

1. hyperfine：先跑很多遍，再报每一遍用掉了什么

为什么今天看

最值得拆的机制

• 它先跑很多次，再报统计量。 默认每个命令至少跑 10 次，并朝 3 秒左右的总时长估算运行次数；-r/--runs 可以写死。4 输出的均值、标准差与最小/最大值，都来自这一批运行。
• 一次测量被拆成四类旁路命令。 --setup 在整组测量前跑一次，--warmup 在测量前跑几次，--prepare 在每次测量前跑，--conclude 与 --cleanup 收尾。4 最常见的用法是让 --prepare 每次先清掉文件系统缓存，把冷缓存和热缓存分开测。
• 2.0 起默认不再经过 shell。 命令被直接执行，参数按类似 shell 的引号规则切分，管道、重定向和通配符都不再被解释。1 需要 shell 语法时加 -S，此时它先单独测一次 shell 的启动耗时，再从每次结果里减掉。
• 指标从「时间」扩成一张表。 --metrics 能选墙钟时间、CPU 时间（用户态与内核态）、内存峰值，以及 CPU 周期、指令数、缓存未命中、分支预测失败这些硬件计数器。4 预设 default 是墙钟时间加内存峰值，time 是四种时间，all 是全部。
• 它带离群值检测。 README 把这条列在特性里，用来发现别的程序抢 CPU 或缓存效应带来的干扰。4
• 结果能导出给别的工具。 --export-json 写出 schema v2 的结构：每次运行、每个指标各一条记录，外加按指标分组的统计摘要。1 --export-markdown 与 --export-csv 各给一份能直接贴进报告的表格。

复现难度：低

最小上手路径

curl -sSL -o hf.tar.gz \
  https://github.com/sharkdp/hyperfine/releases/download/v2.0.0/hyperfine-v2.0.0-x86_64-unknown-linux-musl.tar.gz
tar xzf hf.tar.gz
./hyperfine-v2.0.0-x86_64-unknown-linux-musl/hyperfine --version

hyperfine 2.0.0

hyperfine --warmup 2 -r 8 'sleep 0.05' 'sleep 0.06'

Benchmark 1: sleep 0.05 (8 runs)
                mean     ±       σ          min     …     max
  Wall Time     51.0 ms  ±     0.0 ms      51.0 ms  …    51.1 ms
  Memory         3.5 MiB ±     0.0 MiB      3.5 MiB …     3.5 MiB

Benchmark 2: sleep 0.06 (8 runs)
                mean     ±       σ          min     …     max
  Wall Time     61.1 ms  ±     0.0 ms      61.0 ms  …    61.1 ms           +19.7%
  Memory         3.5 MiB ±     0.0 MiB      3.5 MiB …     3.5 MiB            0.0%

今晚练习

1. 拿两个只差一次 import 的 Python 启动来试内存那一行。本机 python3 -c "pass" 是 36.4 毫秒、峰值 13.2 MiB，python3 -c "import json,re,hashlib" 是 69.2 毫秒、18.7 MiB。
2. 把 hyperfine 'echo hi | wc -l' 原样跑一次。本机报的是 Command 'echo hi | wc -l' contains unquoted shell syntax ('|')，并要求在 -S 与 -N 里选一个；加上 -S 之后它还会提示这条命令不到 5 毫秒、墙钟时间可能测不准。
3. 显式要一个硬件计数器：hyperfine --metrics time_wall_clock:ms,memory_peak_resident:MiB,instructions 'sleep 0.02'。本机报 Metric 'instructions' is unavailable for 'sleep 0.02'，因为硬件计数器要 perf 权限，而这里 /proc/sys/kernel/perf_event_paranoid 是 3。4
4. 用 --parameter-scan 扫一个参数：hyperfine --parameter-scan num_threads 1 4 'sleep 0.{num_threads}'，再看 --export-json 出来的 parameters 字段。4

版本动作与限制

2. httptap：一次 HTTP 请求被切成五段

为什么今天看

最值得拆的机制

• 阶段耗时取自 HTTP 客户端的 trace 钩子。 httptap 用 httpcore 的 trace hooks 记录下 DNS 解析、TCP 连接、TLS 握手、服务端等待与响应体传输的边界时刻，取不到细粒度数据时退回到估算值。9
• 五段在一行里对齐。 瀑布图用每一段的长度表示它占总时长的比例，图标右边标出该段毫秒数，最后一行给总时间，并说明一个字符大约等于多少毫秒。
• TLS 信息是顺手收的。 证书的 CN、SAN、签发者、有效期与剩余天数，加上密码套件与协议版本，都在同一条已经建立的连接上读出来，省掉了第二次握手。9
• 阈值检查是给 CI 用的。 --slo total=500,ttfb=200 给每个阶段设一个毫秒预算，超了就按退出码 4 结束；-f/--fail 遇到 4xx/5xx 退出 22。这套退出码沿用 BSD sysexits.h 的约定，脚本和 CI 能直接判断。9
• 它把自己和同类工具摆在一张表里。 README 逐项列出 httptap、curl -w、httpstat 与 httpie 在阶段计时、瀑布图、JSON 导出、SLO 检查、TLS 检查上的差别，并写明各自适合的场景。9
• 扩展点是 Protocol 接口。 DNS、TLS、计时、可视化和导出各自留有 Protocol 接口，请求执行器也能换成自己的实现。9

复现难度：低

最小上手路径

pip install httptap
httptap https://example.com

  IP: 172.66.147.243 (IPv4) | HTTP: HTTP/2.0 | Proxy: direct | TLS: TLSv1.3 |
Cipher: TLS_AES_256_GCM_SHA384 | Cert: example.com | Issuer: Cloudflare TLS
Issuing ECC CA 3 | Expires: 73d
  Status: 200 | Size: 400 B | Server: cloudflare

Request Timeline:
  ⠿⠿⠿⠿⠿⠿⠿⠿⠿ DNS: 5.2 ms
           ⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿ Connect: 5.7 ms
                     ⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿ TLS: 8.8 ms
                                    ⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿ Wait: 11.8 ms
                                                       ⠿⠿⠿⠿⠿⠿⠿⠿ Transfer: 4.9 ms

Total: 36.5ms (1 char ≈ 0.60ms)

今晚练习

1. httptap --metrics-only https://example.com 只输出一行 key=value，方便脚本读。本机拿到的是 Step 1: dns=5.7 connect=5.6 tls=9.8 ttfb=31.5 total=36.5 status=200 bytes=400 ip=104.20.23.154 family=IPv4 tls_version=TLSv1.3 proxy=direct。
2. 注意那一行里的 ttfb 是从请求开始到收到首字节的累计值，等于 DNS、连接、TLS 三段加上等待段。瀑布图上的 Wait 只是其中最靠后的一段，这里是全篇最容易看错的一处。
3. 故意让阈值失败：httptap --slo total=1 https://example.com。本机退出码是 4，报告仍然完整渲染，失败的那条阈值和超出多少都列在最后。10
4. httptap --json - https://example.com 把结构化结果打到标准输出，顶层是 schema_version、steps、summary，每个 step 的 timing 里分别给 dns_ms、connect_ms、tls_ms、ttfb_ms、total_ms。
5. 同一个域名连跑五次，看 DNS 与 TLS 两段的波动；再加 -4 或 -6 只走一种地址族，比一比连接时间。9

版本动作与限制

3. tuios：一屏终端自己是个有分层的程序

为什么今天看

最值得拆的机制

• 核心是一条从 PTY 到屏幕的链路。 每个窗格是一个伪终端里的 shell，输出流交给 VT 模拟器解析 ANSI 转义序列，结果写进窗口的内容缓存，最后由渲染管线合成整屏。13
• 终端模拟器有两个实现。 默认那个是纯 Go 写的，也能用 -tags ghostty 换成 libghostty-vt；tuios --version 会告诉你手上这个二进制是哪一个。13
• 渲染由事件驱动。 应用按 Bubble Tea v2 的 Model-View-Update 组织，读 PTY 的 goroutine 通过带缓冲的 channel 通知主循环，只在有数据或有交互时重画，没有固定频率的 tick，空闲时 CPU 为 0。13
• 分屏是一棵二叉树。 BSP（二叉空间分割）负责切分，切割方向按螺旋交替，另有主从布局和滚动布局；共享边框模式把窗格矩形故意重叠，再把分隔线画成单独一层。13
• 窗格里的程序可以报告自己在干什么。 任何程序都能用 OSC 7501 报状态，例如 tuios status working --app build --progress 40，这样一个构建脚本就和一个编码 Agent 一样出现在侧栏与收件箱里。14
• 守护进程和客户端分开。 PTY 与模拟器住在守护进程里，客户端只渲染它推过来的内容，所以会话在断开后能重连，也能从另一台机器接上。13

复现难度：低

最小上手路径

curl -sSL -o tuios.tar.gz \
  https://github.com/Gaurav-Gosain/tuios/releases/download/v0.9.2/tuios_0.9.2_Linux_x86_64.tar.gz
tar xzf tuios.tar.gz
./tuios --version

tuios version 0.9.2 [pure-Go backend]
Commit: 937cc6935448c36d2a8e8b3282fe1f76afb6cb6e
Built: 2026-10-09T08:11:42Z

./tuios --standalone   # 不启守护进程，只跑这一次

今晚练习

1. 先用 tuios --standalone 跑一次，再不带参数跑一次，对比两者的会话生命周期——后者挂在守护进程上，终端关掉之后窗格还在。15
2. tuios --list-themes 会列出一长串主题（本机从 3024_day、3024_night 开始），tuios --preview-theme dracula 可以先看颜色再决定。15
3. 打开 internal/vt/ 目录，从 ANSI 解析器的入口读起；再对着 internal/app/render.go，看一次按键事件怎么走到重画。13
4. 让一个普通脚本也出现在侧栏上：跑一次 tuios status working --app build --progress 40，然后看程序状态文档里还允许报告些什么。14

版本动作与限制

怎么选今晚的第一条路径