直接给 stdclass 赋闭包无法调用 fit() 方法，因为 php 对象模型要求方法必须真实存在或通过 __call() 拦截，而 stdclass 不支持 __call() 且不将属性视为可调用方法，导致调用时抛出“call to undefined method”错误。
为什么直接给 stdClass 赋闭包无法调用 fit() 方法
因为 $image->fit(150, 150) 是方法调用语法，PHP 会查找类中是否存在名为 fit 的方法，而不是读取属性并执行它。即使你写 $image->fit = function() {}，stdClass 也不支持“属性即方法”的行为，运行时直接报错：Error: Call to undefined method stdClass::fit()。
这不是语法糖缺失，而是 PHP 对象模型的底层限制：只有真实的方法（或实现 __call() 的类）才能响应 ->xxx() 调用。
-
stdClass不支持自定义魔术方法，__call()在它身上无效 - 试图用
ReflectionProperty或bindClosure强行绑定也无法绕过调用解析阶段 - 这种写法在 PHPUnit 或 Mockery 中都不可靠，且 IDE 无法识别、无类型提示
用匿名类模拟 Image::make() 返回对象的正确姿势
Intervention Image 的 make() 返回一个链式对象，常见方法如 fit()、resize()、save() 都返回 $this。要可靠模拟，必须提供真实方法：
code
$image = new class() {
public function fit($width, $height) {
// 可选：记录调用，便于断言
$this->calledFit = [$width, $height];
return $this;
}
public function resize($width, $height = null) {
return $this;
}
public function save($path = null) {
return true;
}
};
Image::shouldReceive('make')->once()->andReturn($image);
- 每个需测试的方法都得显式声明，不能靠
__call()模糊兜底（否则无法验证参数） - 返回
$this是关键，否则Image::make()->fit()->save()链式调用会中断 - 若需校验参数，直接在方法体内加
$this->assertEquals(150, $width)，比 Mockery 的with()更直观可控
Mock Image 门面时最容易漏掉的兼容点
Intervention Image 的门面实际代理的是静态调用，但底层对象是实例化的。Mock 时容易忽略三点：
-
Image::make()必须返回一个支持链式调用的对象，否则后续方法调用直接失败 -
Image::cache()、Image::response()等静态方法也要单独shouldReceive()，否则未定义调用会触发 fatal error - 如果测试中用了
Image::make($file)->encode('jpg')，那encode()方法也得在匿名类里声明，不能假设“没调用就不写”
尤其注意：Laravel 测试环境下，门面类可能被重绑定（如 App::bind('image', ...)），此时仅 Mock Image 类不够，需确保服务容器中的绑定也被替换或跳过。
不推荐用内存 SQLite 或真实 GD 驱动做图像单元测试
图像处理逻辑本身不涉及 I/O 或外部状态，用真实驱动会引入不可控变量：
- GD 扩展是否启用、版本差异（如某些
imagecopyresampled()行为在 PHP 8.2+ 有微调）会导致测试结果不稳定 - 生成临时文件再读取，违背单元测试“快速、隔离”原则，且文件权限、路径问题常导致 CI 失败
- 哪怕只测
fit()是否被调用，也完全不需要像素级验证——那是集成测试的事
真正该测的是：输入路径后，是否调用了 fit(150, 150)；是否在异常路径下抛出预期异常；是否按条件跳过处理。这些全靠轻量匿名类 + 明确方法声明就能覆盖，无需碰真实图像数据。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
