用应用本就在产生的流量来生成 API 测试

你点着走完一个流程，应用会发出一串请求：往 /api/orders 发的 POST、重新加载列表的 GET、你改字段时发的 PATCH。这些请求就是你的 API 契约，正在实时跑着。大多数 API 测试工具却把它们晾在一边，让你对着一份 spec 文档，手动再把契约描述一遍。

Hover 直接从浏览器读取这些请求

你用那套有据可查的工具驱动应用时，Hover 会盯着 CDP 的 Network 事件，把 xhr 和 fetch 调用留下来。capture_requests 把应用真正发出和收到的东西交给你：method、URL、status，还有响应结构。没有代理要配，也没有 MITM 证书要信。流量本来就在浏览器里。

crystallize_api_spec 把你选中的那几个调用，变成一份基于 Playwright request fixture 的 *.api-test.spec.ts。它运行时不开浏览器，所以很快，而且能给你一个 UI spec 给不了的失败信号：当 API spec 变红、UI spec 却还绿着，说明你的契约在一个碰巧还能正常渲染的页面底下，已经变了。

上线前先探一探访问控制

replay_request 会把某个调用重新发一遍，好让你测它。设成 authenticated: false，Hover 就用一个没有会话的全新上下文来发——你要验证 GET /api/orders/42 会不会拒掉一个不属于你的请求，靠的就是这招。这正是每个应用都该做、却很少有人做的越权访问（broken-access-control）测试。

你的会话不进 git

你探索的时候，抓下来的请求带着你的 cookie 和 auth header。结晶时会把它们从 spec 里拿掉，就像填凭据时会脱敏成 process.env 一样。你提交的，是一份断言契约的测试，而不是把你的实时会话粘进版本控制的测试。

一次运行，两层都给你。把 checkout 走一遍：UI spec 断言确认页渲染出来，API spec 断言 POST /api/orders 返回了带 order id 的 201，越权检查确认换个用户读不到这笔订单。一次会话，三样产物，全是纯 Playwright。

阅读 API 测试文档 →