Guzzle需在真实场景中调试掌握，关键是从解决当前请求报错入手；响应体是StreamInterface，须转字符串或解码；form_params与json参数不可混用；4xx/5xx默认不抛异常，需设http_errors=>true。
Guzzle 不是靠“学完教程”就能用好的库，它得在真实请求场景里反复调、踩坑、改配置才能真正上手。直接告诉你最关键的判断：**别从文档首页开始读，先解决你正在写的那行 $client->get() 报错或拿不到数据的问题**。
为什么 $response->getBody() 打印出来是空的或乱码
这不是代码写错了，是没意识到 Guzzle 返回的是 StreamInterface 对象，不是字符串。直接 echo 或 print_r 会输出对象地址或空内容。
- 必须显式转成字符串：
(string)$response->getBody()或$response->getBody()->getContents() - 如果接口返回的是 JSON，还得再解码：
json_decode((string)$response->getBody(), true) - 遇到 GBK、BIG5 等非 UTF-8 响应，
getContents()拿到的是原始字节，得手动转：mb_convert_encoding($response->getBody()->getContents(), 'UTF-8', 'GBK') - 注意：多次调用
getContents()第二次会返回空——流只能读一次，要重复用就先存成变量
form_params 和 json 参数不能混着用
这是最常被忽略的底层差异。Guzzle 对这两类参数做了完全不同的处理逻辑，混用会导致服务端收不到字段。
-
form_params：自动设Content-Type: application/x-www-form-urlencoded，并用http_build_query()编码键值对 -
json：自动json_encode()数组，并设Content-Type: application/json - 错误示范：
['json' => [...], 'form_params' => [...]]—— Guzzle 只认其中一个，另一个被静默丢弃 - 传文件必须用
multipart，form_params里塞CURLFile会被当字符串发过去，后端根本解析不了
404/500 不抛异常？因为默认 http_errors => false
很多人以为 try/catch RequestException 能捕获所有失败，结果 404 页面返回了却没进 catch——因为 Guzzle 默认把 HTTP 状态码错误当成“正常响应”处理。
- 想让 4xx/5xx 主动抛
RequestException，初始化 Client 时加配置：['http_errors' => true] - 不加这个，就得自己判断：
if ($response->getStatusCode() >= 400) { ... } - 超时也分两级：
timeout控整个请求耗时（含 DNS、连接、传输），connect_timeout只控建连阶段；后者默认是 0（不限），DNS 卡住就一直挂住，建议显式设为 3–5 秒
异步请求别硬套 Promise::settle() 就完事
用 guzzlehttp/promises 并不等于自动并发。Promise 本身不触发网络请求，只是包装一个“将来会完成的操作”。真正并发靠的是 Client 实例复用 + 异步方法（如 getAsync()）。
立即学习“PHP免费学习笔记（深入）”；
- 错误做法：循环里 new Client 再调
getAsync()—— 连接池失效，性能反而更差 - 正确姿势：单例 Client + 收集所有 Promise，再用
Promise\settle()或Promise\all()统一等待 -
wait()是同步阻塞的，别在 Web 请求中直接调；需要非阻塞就得配合事件循环（如reactphp），Guzzle 自身不提供 - Promise 链里 throw 的异常，会被下游
then(null, $onRejected)捕获，但不会中断整个链——这点和 JS 的 async/await 行为不同
get() 其实触发了 302 跳转、或者响应体已经被其他中间件提前读空了。调试时优先看 $response->getHeaders() 和原始 getContents()，比猜逻辑更快。 
