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() 包裹，否则带空格或特殊字符的值会直接崩掉命令执行。