go http抓包不能只靠net/http.transport，因其默认复用连接、启用http/2、跳过代理且底层抽象丢失tls/头序等关键上下文；可靠方式是自定义roundtripper拦截或包装net.conn，配合httputil.dump获取wire格式，但tls细节需代理或pcap辅助。
Go HTTP 请求抓包为什么不能只靠 net/http.Transport？
因为 net/http.Transport 默认复用连接、启用 HTTP/2、跳过代理检查，且底层使用 net.Conn 抽象，直接监听或替换它会丢失请求头原始顺序、压缩状态、TLS 信息等关键上下文。你看到的「抓到包但内容乱码/不完整/没 header」，大概率是绕过了 TLS 握手或忽略了 http.Request.Write 的实际序列化逻辑。
真正可控的切入点只有两个：在请求发出前「拦截并记录」，或在 Transport 底层套一层可观察的 net.Conn。前者简单但漏掉重定向、自动 gzip 解压等隐式行为；后者完整但必须处理 TLS、HTTP/2、连接池复用带来的状态干扰。
用 RoundTrip 拦截器记录原始请求/响应最稳妥
给 http.Client 配一个自定义 http.RoundTripper，在调用下游 RoundTrip 前后分别深拷贝 *http.Request 和 *http.Response —— 注意不是浅拷贝，否则 body 会被 consume 一次就变空。
- 用
httputil.DumpRequestOut和httputil.DumpResponse获取原始 wire 格式（含 status line、raw headers），但它们不支持 streaming body，需先ioutil.ReadAll或用io.TeeReader辅助 -
req.Header.Clone()只复制 header map，不包含 trailer 或 Transfer-Encoding 等传输层字段，别依赖它还原真实请求流 - 若需支持 HTTP/2，确保你的拦截器不破坏
req.Body的io.ReadCloser接口契约，否则 gRPC 或流式接口会 panic
想看 TLS 握手细节就得换掉 crypto/tls.Conn
标准库里没有暴露 TLS 层 Hook，所以得自己实现 tls.Conn 包装器，在 Write / Read 时把加密前的明文（ClientHello/ServerHello）和密文都记录下来。但这意味着你要手动构造 net.Conn 并注入到 http.Transport.DialContext 返回值中。
常见坑：http.Transport.TLSClientConfig 的 GetClientCertificate 回调会在每次握手前触发，但它只给你证书选择权，不让你看到 ClientHello 内容；而 VerifyPeerCertificate 是握手后才调用，此时密钥已协商完成，看不到早期密文。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
更现实的做法是：用 golang.org/x/net/proxy 配一个本地 socks5 代理（如 mitmproxy），让 Go client 走代理，再在代理端解密 —— 这样不用动 TLS 层，也兼容 HTTP/1.1 和 HTTP/2。
不要在生产环境用 httptrace 或 log middleware 替代抓包
httptrace.ClientTrace 只能拿到 DNS、connect、TLS 时间点，拿不到任何 payload；而中间件式日志（比如在 handler 里打 log）只适用于你控制 server 端，对第三方 API 调用完全无效。
如果你只是想调试自己写的 client 调用，优先用 httputil.DumpRequestOut + 自定义 RoundTripper；如果要分析线上流量或排查 TLS 错误，老老实实上 pcap + Wireshark，或者用 eBPF 工具（如 bpftrace）在 socket 层捕获，Go runtime 层面做不到无侵入全量抓包。
真正难的从来不是「怎么拿到数据」，而是「拿到的数据是否反映真实网络行为」—— 比如 HTTP/2 流多路复用下，一个 TCP 连接里混着几十个 request/response frame，按顺序 dump 出来却无法对应到具体 Go goroutine，这种关联性丢失，代码层基本无解。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
