composer test 不是 Composer 自带命令，仅当 composer.json 的 scripts 中明确定义了 "test" 键时才存在；未定义则报错“Command 'test' is not defined”，因 Composer 本身不预置该命令，仅作脚本路由代理。
直接说结论：composer test 不是 Composer 自带命令，它只在你明确定义了 "scripts": { "test": "..." } 时才存在；没配就跑，必报 Command "test" is not defined。
为什么 composer test 有时根本不存在
Composer 本身不预置 test 命令，它只是脚本路由代理。是否能用，完全取决于你的 composer.json 顶层有没有 "scripts" 字段，且该字段内是否包含 "test" 键。
- 检查方法：运行
composer run-script --list，看输出里有没有test - 旧版 Composer（composer test:unit 这种带冒号的写法，必须用
composer run "test:unit"或composer run-script "test:unit" - 如果脚本名含空格或特殊字符（如
"test:ci"），传参时务必用双引号包裹：composer run "test:ci" -- --verbose
"test" 脚本值该写什么才跨平台可靠
别写 "test": "phpunit" —— Windows 下找不到命令，Linux/macOS 又依赖 $PATH，CI 里十次九挂。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 统一写成
"test": "vendor/bin/phpunit"：所有平台都走这个路径（Windows 实际调的是vendor/bin/phpunit.bat） - 用了 PHPUnit 10+，加
--colors=always：避免 CI 环境禁用颜色导致断言输出被截断或误判 - 想固定跑某个目录？直接写死路径：
"test": "vendor/bin/phpunit tests/Unit"，比靠参数传递更可控、更可复现 - 数组写法（如
"test": ["@test:unit", "@test:feature"]）需 Composer ≥ 7.0，老项目慎用
参数怎么传：漏掉 -- 就全错
composer test -- --filter=MyTest 和 composer test --filter=MyTest 是两回事。
- 前者：第一个
--告诉 Composer “后面全是给脚本的参数”，--filter=MyTest会透传给phpunit - 后者：Composer 把
--filter当作自身选项处理，大概率报错或静默忽略 - 自定义 PHP 入口（如
"test": "php test-runner.php"）中，参数从$argv[2]开始；更稳的方式是读getenv('COMPOSER_ARGS')（Composer ≥ 4.0）
CI 里类找不到？八成不是 PHPUnit 配错了
本地 composer test 成功、CI 报 Class 'MyPackage\Calculator' not found，90% 是 autoload 没对齐或 CI 没加载 dev autoload。
- CI 默认执行
composer install --no-dev，只加载autoload段，完全忽略autoload-dev—— 如果你的TestCase在tests/里且进了autoload-dev，但src/里又use了它，就炸 -
phpunit.xml.dist必须有三样：bootstrap="vendor/autoload.php"、<directory>tests</directory>、<source><directory>src</directory></source> - CI 中记得加
composer dump-autoload --dev --optimize：生成高效 classmap，绕过 PSR-4 文件探测失败风险
最容易被忽略的点是：autoload-dev 配置生效 ≠ 类能被找到，中间卡在 dump-autoload --dev 这一步的人最多；而一旦跨过这关，后续模块（如 phpstan、php-cs-fixer）的集成，反而只是加几行命令的事。
