run-script 后的参数透传给被调用脚本，需用 -- 分隔；PHP 脚本须写成 php -- script.php 才能通过 $argv 接收，否则参数被 PHP 解释器截获。
run-script 后面加参数到底传给谁？
Composer 的 run-script 命令本身不解析参数，所有写在命令末尾的参数（比如 composer run-script build -- --env=prod 中的 -- --env=prod）默认会原样透传给被调用的脚本——但前提是脚本本身能接收并处理它们。很多人卡在这一步：以为加了 -- 就自动生效，结果脚本里 $argv 或 process.argv 根本收不到。
关键点有三个：
-
--是必须的，用来分隔 Composer 自身参数和脚本参数 - 脚本类型决定参数接收方式：PHP 脚本靠
$argv，Shell 脚本靠$@，Node.js 靠process.argv.slice(2) - 如果脚本是通过
php some-script.php这种方式定义在scripts里，那参数必须出现在php命令之后、脚本路径之前，否则会被 PHP 解释器吞掉
PHP 脚本中正确读取 --env=prod 这类参数
假设你在 composer.json 里写了：
"scripts": {
"build": "php build.php"
}
那么执行 composer run-script build -- --env=prod 时，build.php 收不到 --env=prod——因为参数被 php 进程吃掉了。正确写法是把参数显式塞进命令行：
"scripts": {
"build": "php build.php"
}
然后改用：
composer run-script build -- -- --env=prod
注意这里用了两个 --：第一个是 run-script 的分隔符，第二个才是传给 php 的，表示“后面这些别让 PHP 解析，直接透传给脚本”。这时 build.php 才能通过 $argv 拿到：
更健壮的做法是用
getopt()解析：Shell 脚本或 Node.js 脚本怎么接参数？
Shell 脚本最简单，参数天然可用：
"scripts": { "deploy": "sh deploy.sh" }执行
composer run-script deploy -- --stage=staging --force，deploy.sh里直接用$@或$1、$2即可：#!/bin/sh echo "Stage: $1" # 输出：Stage: --stage=staging # 实际建议用 getopts 或 case 处理Node.js 脚本要注意：
process.argv前两项固定是node和脚本路径，有效参数从索引2开始："scripts": { "lint": "node lint.js" }运行
composer run-script lint -- --fix --ext=ts，lint.js中：console.log(process.argv.slice(2)); // ['--fix', '--ext=ts']推荐用
minimist或yargs解析，避免手撕字符串。为什么 --foo=bar 在 Windows 上有时失效？
Windows CMD 对等号
=和引号处理很敏感。比如composer run-script test -- --path=C:\tmp可能被截断或报错。根本原因是 CMD 把C:\tmp当成两个词（C:和\tmp），中间空格丢失。解决办法只有两个：
- 改用 PowerShell 或 Git Bash 执行命令（推荐）
- 强制加双引号，并确保 Composer 版本 ≥ 2.2（旧版对引号支持差）：
composer run-script test -- "--path=C:\\tmp"
另外，如果脚本里用 exec() 或 shell_exec() 再次拼接参数，务必用 escapeshellarg() 包裹，否则带空格或特殊字符的值会直接崩掉命令执行。
