Composer不支持PHP内联脚本，因其无法加载autoloader、不参与事件生命周期且不可透传参数；应使用@php调用独立脚本或PHP静态方法回调，并确保autoload加载和错误处理。
PHP脚本片段（inline）在Composer中根本不可用
不能。Composer不支持直接执行PHP代码片段，比如"build": "php -r "echo 'done';""这类写法看似能跑，但实际是靠系统shell调用php二进制，不是Composer原生能力——它既无法加载项目autoloader，也不参与事件生命周期，更没法透传参数或捕获退出码。
常见错误现象：你写了"test": "var_dump('hello')"，结果报sh: var_dump: not found；或者php -r里用了new AppTask()，却提示Class not found——因为vendor/autoload.php根本没加载。
- Composer的
scripts字段只接受三种值：字符串命令、命令数组、PHP静态方法回调（如"MyClass::doIt"） -
php -r属于外部进程，完全脱离Composer上下文，autoloader、路径、环境变量全不继承 - 即便语法侥幸通过，也违背幂等性、可测试性和错误处理原则，CI/CD中极易静默失败
想快速执行单行逻辑？用@php + 独立脚本替代
真正安全的做法是把一行逻辑封装成最小化脚本文件，再用@php调用。这样既能复用autoloader，又便于调试和加日志。
例如，你想输出当前环境配置：
立即学习“PHP免费学习笔记（深入）”；
// scripts/env.php <?php require __DIR__ . '/../vendor/autoload.php'; echo $_ENV['APP_ENV'] ?? 'dev' . PHP_EOL;
然后在composer.json中定义：
"scripts": {
"show-env": "@php scripts/env.php"
}
-
@php确保使用Composer绑定的PHP版本，避免系统多版本冲突 - 脚本路径必须相对于项目根目录（即
composer.json所在位置），不能写./scripts/ - 文件需有执行权限（Linux/macOS）：
chmod +x scripts/env.php，Windows也建议统一加@php前缀 - 别省略
requireautoload —— 这是类能被找到的唯一前提
PHP静态方法回调比inline更可控，但限制多
如果你坚持用PHP代码而非脚本文件，唯一合规方式是定义public static方法，并在scripts中引用，例如"cleanup": "App\Scripts\Cleaner::run"。
但这要求：
- 类必须已声明在
autoload或autoload-dev中，且已运行过composer dump-autoload - 方法必须是
public static，签名兼容$event参数（即使不用也要预留） - 无法接收命令行参数——
--分隔符对静态方法无效，参数透传只适用于@php调用的脚本 - 错误退出码不会自动传播，需手动
exit(1)，否则Composer认为成功
参数传递和错误处理必须显式处理
所有inline幻想都绕不开参数和错误——而这两点恰恰是Composer脚本最易出错的地方。
比如你想传一个环境名给清理脚本：
- 错误写法：
composer cleanup --env=prod→--env=prod被Composer自己吃掉，脚本收不到 - 正确写法：
composer run-script cleanup -- --env=prod，且脚本内必须读getenv('COMPOSER_ARGS')或解析$argv（注意索引偏移） - 脚本执行失败时，若没显式
exit(1)，Composer默认返回0，CI流程会误判为成功 - 推荐在脚本开头加防护：
if (!class_exists('ComposerAutoloadClassLoader')) { exit(1); }
真正麻烦的从来不是“怎么写一行代码”，而是“怎么让这一行在所有环境里稳定、可观测、可中断”。inline脚本省下的那几行代码，最后都会变成CI日志里查不出原因的Exit code 0。
