Composer脚本不支持直接调用PHP函数，仅执行shell命令；必须通过"php script.php"或"@php script.php"运行脚本文件，且PHP脚本需手动加载autoload并用__DIR__处理路径。
Composer 脚本本身不支持直接“调用 PHP 函数”，它只执行 shell 命令；所谓“调用函数”，本质是运行一个 PHP 脚本文件，再由该脚本内部去调用你的函数——这是最可靠、最可控的方式。
脚本值必须是可执行命令，不能写函数调用
你在 composer.json 的 scripts 字段里写的值，必须是操作系统能识别的命令字符串，比如 "php scripts/deploy.php" 或 "@php scripts/clear.php"。写成 "AppScriptsDeploy::run()" 或 deploy() 会直接报错：Command "deploy()" is not defined。
- Composer 不解析 PHP 语法，也不加载任何类或函数
- 它只是把字符串丢给 shell 执行，就像你在终端敲下那行命令一样
- 哪怕你写了
"php -r 'echo App\Helper::now();'"，也得确保AppHelper已通过 autoloader 可用（否则 Class not found）
@php 是安全调用 PHP 的关键
用 @php 替代裸写 php，能避免因系统 PATH 混乱导致的 PHP 版本错配问题，尤其在多版本环境（如 asdf、phpbrew）下更稳定。
-
"migrate": "@php artisan migrate"→ Composer 自动找它自己用的 PHP 二进制 -
"migrate": "php artisan migrate"→ 走系统 PATH，可能和composer install用的不是同一个 PHP - 如果脚本依赖
ext-redis或ext-pdo_pgsql，错用 PHP 就直接PHP Fatal error: Call to undefined function redis_connect()
PHP 脚本里必须手动加载 autoload 并处理路径
哪怕你只写了一行 new AppServiceNotifier();，没加载自动加载器就必然失败。而且当前工作目录不可靠，必须用 __DIR__ 定位文件。
- 开头必须加：
require __DIR__ . '/vendor/autoload.php'; - 别写
require 'vendor/autoload.php'—— 相对路径以执行时 CWD 为准，而 CWD 不一定是项目根目录 - 配置文件、SQL 文件等资源路径也要用
__DIR__ . '/../config/app.php'这种方式，不依赖chdir()或getcwd() - 如果你用的是 Laravel/ Symfony 等框架的 Artisan 命令，它们内部已处理 autoload，但自定义脚本没有这个待遇
传参要靠 $argv + 显式 -- 分隔
想让 composer build -- --env=prod --force 中的 --env=prod 传进 PHP 脚本，必须用双短横线 -- 告诉 Composer：“后面全是子进程参数”，否则会被 Composer 自己吃掉。
- 脚本中读取：
$env = $argv[2] ?? 'dev'; // 对应 --env=prod 中的 prod，或用getopt()解析 - 更健壮的做法是改用
getenv('COMPOSER_ARGS')（Composer 4.0+ 提供），它返回原始参数字符串，避免索引错位 - 不要依赖
$_SERVER['argv']—— 在某些 CLI SAPI 下它可能被截断或污染 - 数组形式脚本值（如
["php", "scripts/build.php"]）会原样透传$argv，适合需要精细控制参数顺序的场景
最容易被忽略的一点：脚本名大小写和短横线必须完全匹配 composer.json 中定义的键，Windows 下带冒号或短横线的脚本名还得加英文双引号包裹，比如 composer run "dev:start" —— 少一个字符、多一个空格，就是 Script not found。
