Composer生态中Mock测试的性能瓶颈源于加载方式、生命周期管理及PHP运行模式；Mockery默认依赖eval()，在PHPUnit 10+禁用processIsolation时需改用namedMock()或调整配置；安装失败多因PHP版本不匹配或minimum-stability策略限制；Class not found主因是autoloader未引入或命名空间错误；spy()会执行原方法并带副作用，mock()才完全拦截；必须调用Mockery::close()防内存泄漏，推荐复用mock实例提升性能。
Composer生态里做Mock测试，性能瓶颈往往不出在框架本身，而在于加载方式、生命周期管理和PHP运行模式——尤其是Mockery::mock()默认依赖eval()，在PHPUnit 10+默认禁用processIsolation="false"时直接报错。
Mockery安装失败：PHP版本与minimum-stability冲突
常见错误是Could not find package mockery/mockery或一堆版本不满足提示。这不是包不存在，而是Composer被PHP版本或稳定性策略卡住。
- 先确认PHP版本：
php -v；若低于8.0，别硬上mockery/mockery:^1.6，改用mockery/mockery:^1.5（兼容PHP 7.3+） - 检查
composer.json是否含"minimum-stability": "stable"；如有且没配"prefer-stable": true，预发布版可能被跳过——删掉这行，或显式加--stability=dev - 国内用户卡下载，换源比重试更有效：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
Class 'Mockery' not found：autoloader没生效
装完mockery/mockery却跑不起来，90%是因为vendor/autoload.php没在测试入口里引入，或命名空间没写对。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- PHPUnit启动前必须
require 'vendor/autoload.php'；Laravel项目通常已做，但自建测试脚本容易漏 - 别在
setUp()里写Mockery::close()却不use Mockery;——PHP会当成全局类找，而Mockery是命名空间类，必须use Mockery\MockInterface;或写全名\Mockery::mock() - PHPUnit 10+默认禁用
eval()，而Mockery::mock()默认靠它生成动态类；要么在phpunit.xml里加processIsolation="false"，要么改用Mockery::namedMock()避开eval
mock() vs spy()：副作用误触发导致测试不稳定
很多人以为Mockery::spy()只是“记录调用”，其实它不拦截原方法执行——如果被spy的对象里有HTTP请求、数据库写入或日志输出，这些都会真实发生。
-
Mockery::mock()：完全拦截方法，返回预设值，原逻辑不执行 -
Mockery::spy()：原方法照常执行，同时记录调用；适合验证“是否被调用”，但绝不适合有副作用的场景 - 清理必须做：
Mockery::close()应在tearDown()或测试末尾调用，否则残留mock会影响后续测试——尤其在共享进程的CI环境中
真正影响Mock性能的不是模拟逻辑本身，而是每次测试后没调用Mockery::close()导致内存泄漏，或在setUp()里反复创建大量mock对象却不复用。高频测试下，建议把常用mock实例缓存到static属性，而不是每个测试都重建。
