应Mock HTTP通信层而非业务服务类，优先使用Guzzle的MockHandler或拦截curl_exec等I/O函数；需确保响应状态码、headers与真实服务一致，避免复用MockHandler实例，并关闭opcache以保证函数拦截生效。
PHP单元测试中Mock外部HTTP服务调用
直接Mock file_get_contents、curl_exec 或 Guzzle 的底层调用，比试图Stub整个客户端更可控。真实项目里，你几乎不会去Mock一个封装好的Service类本身（比如 PaymentService），而是Mock它依赖的HTTP通信层——否则测试就绕过了实际请求组装、错误重试、超时处理等关键逻辑。
- 优先Mock网络I/O函数（如
curl_exec），而非业务类：PHPUnit的functionMock或 Patchwork 可以拦截全局函数调用 - 若用 Guzzle，推荐替换
GuzzleHttp\Client的handler选项为MockHandler，这是官方支持方式，不侵入业务代码 - 避免在测试中修改
php.ini禁用allow_url_fopen来“阻止”真实请求——这属于破坏性隔离，不是Mock
用MockHandler伪造Guzzle HTTP响应
MockHandler 是 Guzzle 自带的测试工具，它让 Client::request() 返回预设的 Response 对象，而不是发真实请求。关键在于：它只影响被注入该 handler 的 Client 实例，不影响其他地方。
$mock = new MockHandler([
new Response(200, [], '{"status":"ok"}'),
new Response(500, [], 'Internal Server Error'),
]);
$handler = HandlerStack::create($mock);
$client = new Client(['handler' => $handler]);
// 此次调用不会发网络请求，返回第一个Response
$response = $client->get('https://api.example.com/health');
- 每个
Response按调用顺序返回；超出数量会抛出Exception，可用于验证是否多调用了一次 - 可传入
Stream对象模拟大文件响应体，避免内存占用问题 - 不要在
setUp()中复用同一个MockHandler实例跨多个测试方法——状态会残留，导致偶发失败
Mock curl_exec时必须禁用opcache优化
当使用 functionMock（如 PHPUnit 的 getMockBuilder()->setMethods(null)->disableOriginalConstructor() 配合 Patchwork）拦截 curl_exec 时，如果启用了 opcache，PHP 可能跳过函数调用拦截，导致仍发出真实请求。
- 测试环境务必设置
opcache.enable=0（CLI下可通过php -d opcache.enable=0 vendor/bin/phpunit临时关闭） - 确认
curl_exec确实被拦截：在Mock回调里加echo "mocked"; die;，看是否输出 - 注意
curl_setopt和curl_init不需要Mock——只要curl_exec返回假数据，后续逻辑自然走通
为什么不该Mock整个服务类（如 ApiService）
Mock ApiService 类本身，等于把它的所有方法（包括请求构造、参数校验、JSON解析、异常映射）全跳过。这时你测的只是“我调了这个方法”，而不是“它在各种HTTP状态码下是否按预期处理”。这种测试脆弱且价值极低。
立即学习“PHP免费学习笔记（深入）”；
- 真正要验证的是：当接口返回
401时，是否抛出UnauthorizedException；当返回200但 JSON 缺字段时，是否抛出ParseException - 这些逻辑都在服务类内部，必须让它运行，只隔离网络层
- 如果服务类没有明确分离HTTP客户端依赖（比如直接 new GuzzleClient()），先重构——提取客户端为构造函数参数，再注入 MockHandler 实例
最常被忽略的一点：Mock响应里的 headers 和 status code 必须和真实服务一致。比如某些API用 204 No Content 表示成功但无body，如果你Mock成 200 + 空字符串，可能掩盖 json_decode('', true) 返回 null 导致的NPE。细节决定Mock是否真能守住边界。
