直接运行 composer run 或 composer [script-name] 触发脚本，composer run-script 已弃用；脚本名须严格匹配 composer.json 中 scripts 键，区分大小写且不模糊匹配；运行时需注意工作目录、自动加载、环境变量及跨平台兼容性。
直接运行 composer run 或 composer [script-name] 即可触发脚本，composer run-script 已被标记为弃用，不推荐在新项目中使用。
脚本名必须严格匹配 composer.json 中的键
Composer 不做模糊匹配、不自动补全、不忽略大小写。比如定义了 "dev-start": "php -S localhost:8000"，就必须用 composer dev-start（或 composer run dev-start），写成 dev_start、devstart 或 Dev-Start 都会报 Script not found。
- 检查
composer.json里"scripts"是顶层字段，没被缩进到require或其他块内 - Windows 命令行中若脚本名含短横线（如
ci:build），需加双引号：composer run "ci:build" - 运行
composer run --list可列出所有已注册脚本，这是最可靠的验证方式
传参必须用 -- 显式分隔
想把 --filter=MyTest 传给 PHPUnit，不能写 composer test --filter=MyTest——这个参数会被 Composer 当作自身选项处理，大概率报错或静默丢弃。
- 正确写法是：
composer test -- --filter=MyTest，中间的--是 Unix shell 约定，表示“后面全是子进程参数” - 如果脚本值是数组（如
["php", "tests/run.php"]），参数会原样透传给php进程，$argv可直接读取 - PHP 脚本中避免依赖
$_SERVER['argv']，建议改用getenv('COMPOSER_ARGS')（Composer 4.0+ 提供）或手动解析$argv索引
PHP 脚本要手动加载 autoloader
composer run 默认不自动 require vendor/autoload.php，所以直接 new 一个类或调用框架方法，大概率报 Class not found。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- PHP 脚本开头必须显式加载：
require __DIR__ . '/vendor/autoload.php'; - 不要假设当前工作目录是项目根目录——脚本执行时 CWD 是
composer.json所在路径，但相对路径仍以该目录为基准 - 推荐把逻辑封装成独立 PHP 文件（如
scripts/deploy.php），再在scripts中写"deploy": "php scripts/deploy.php"，比内联 shell 更可控
慎用 shell 命令，跨平台和错误处理是硬伤
写 "build": "npm run build && cp dist/* public/" 看似简洁，但在 Windows CMD 下 && 会失败，$PATH 可能不含 npm，且错误无法捕获。
- 多步骤逻辑优先用 PHP 脚本替代，可用
try/catch捕获异常，并返回非零退出码中断后续流程 - 若必须用 shell，路径一律用
./vendor/bin/phpunit而非phpunit，避免依赖全局PATH - 环境变量默认不继承（如
.env文件内容），需要读取时得自己parse_ini_file()或用symfony/dotenv
真正容易被忽略的是：脚本执行上下文和你手动敲命令时完全不同——它不继承 shell 的 PATH、不加载 .env、不自动 cd 到子目录、也不保证 php 版本和 CLI 一致。调试时第一反应不该是“脚本写错了”，而是“执行环境和预期不一致”。
