单元测试环境必须慎用composer install --no-dev，因为它会剔除phpunit等必需工具并删除autoload-dev映射，导致Class 'PHPUnitFrameworkTestCase' not found等错误；正确做法是在CI测试阶段执行不带--no-dev的composer install，确保dev依赖全量安装且autoload-dev规则生效。
composer install --no-dev 为什么在单元测试环境里反而要慎用
单元测试环境不是生产环境，--no-dev 会直接剔除 phpunit、mockery、phpstan 等必需工具，导致 vendor/autoload.php 缺失测试类自动加载规则，Class not found 报错。测试环境需要的是“精准装 dev 包”，而不是“不装 dev 包”。
常见错误现象：
- 运行
phpunit报Fatal error: Class 'PHPUnitFrameworkTestCase' not found -
composer install --no-dev后vendor/composer/autoload_dev.php消失，但测试入口仍依赖它 - Docker 构建时缓存复用旧
composer.lock，误把生产构建的 lock 文件用于测试镜像
正确做法是明确区分用途：
- CI 测试阶段：用
composer install（不加--no-dev），确保autoload_dev.php生成且require-dev全量安装 - 若需加速，配合镜像源 +
--prefer-dist，而非删包 - 避免在测试脚本里硬写
new TestsFooTest()，改用 PHPUnit 的 XML 配置或注解驱动发现机制
单元测试环境必须保留 autoload-dev 映射，但不能污染生产 autoload
autoload-dev 不是开关，是 PSR-4 路径映射规则，它只在 vendor/autoload.php 被 require 时才生效。问题出在“谁 require 了它”以及“是否被写入主 autoload 文件”。
关键点：
-
composer install时，若require-dev存在，Composer 会把autoload-dev里的路径合并进vendor/autoload.php—— 这是默认行为，不是 bug - 但只要你不主动
require 'vendor/autoload.php'（比如在phpunit.xml的bootstrap里指定vendor/autoload.php），就不会加载测试类 - 真正危险的是：某些框架（如 Laravel）的
phpunit.xml默认 bootstrap 是vendor/autoload.php，而它已含Tests映射；一旦线上代码误调new TestsFooTest()，就会触发 fatal error
验证方式：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 检查
vendor/autoload.php是否包含Tests相关addPsr4调用（grep -n "Tests\" vendor/autoload.php） - 确认
phpunit.xml的<bootstrap>指向的是vendor/autoload.php，而非自定义引导文件 - 生产环境入口（如
public/index.php）里绝不能出现use Tests或new Tests
镜像源对单元测试构建的影响仅限于下载速度，不改变依赖解析逻辑
换阿里云/清华镜像后 composer update 仍卡在 Resolving dependencies，和镜像无关。单元测试环境常因以下原因变慢：
-
composer.json中"php": "^7.4 || ^8.0 || ^8.1 || ^8.2 || ^8.3"这类宽泛约束，让 Composer 尝试所有 PHP 版本兼容组合 -
require-dev里混入大量未锁定版本的dev-main包，每次解析都要重新 fetch 元数据 - CI 中未设置
config.platform.php，导致本地 PHP 8.3 解析出的 lock 文件，在 PHP 8.1 测试节点上反复重算
提速实操建议：
- 测试 CI 节点统一配置
composer config --global config.platform.php "8.1.0"（注意写死小版本号，"^8.1"无效） - 把
phpunit等核心测试工具锁死版本，例如"phpunit/phpunit": "10.5.10"，避免dev-main带来的不确定性 - 用
composer install -vvv观察日志，若卡在GET https://mirrors.aliyun.com/composer/packages.json→ 镜像生效；若卡在Resolving dependencies→ 查 PHP 版本约束或 dev 包版本漂移
Docker 构建单元测试镜像时，vendor 和 cache 必须隔离
最常踩的坑是：把宿主机 vendor/ 或 ~/.composer/cache COPY 进容器，导致权限错乱、PHP 版本不匹配、甚至缓存污染引发 Signature mismatch 错误。
正确分层构建逻辑：
- Dockerfile 第一层只 COPY
composer.json+composer.lock，RUNcomposer install --no-interaction --prefer-dist（不加--no-dev） - 第二层 COPY 应用代码，不覆盖
vendor/—— 因为测试环境需要完整 autoload - 禁止挂载
~/.composer/cache到容器内；改用composer install --no-cache或利用 Docker BuildKit 的cache-from机制复用 dist 包 - 若使用
lee88688/aider-composer这类预装镜像，确认其内部已配置镜像源且未固化--no-dev参数
镜像构建完成后，用 docker run --rm -v $(pwd):/app -w /app your-image php -r "require 'vendor/autoload.php'; echo class_exists('PHPUnit\Framework\TestCase') ? 'OK' : 'FAIL';" 快速验证 autoload 可用性。
