Composer 的 scripts 是最直接的别名实现方式，通过 composer.json 的 scripts 段定义项目级命令（如 "du": "composer update"），用 composer run du 执行，支持跨平台、组合调用（@xxx）和多命令数组。
Composer 的 scripts 是最直接的别名实现方式
Composer 本身不支持 Unix 风格的 alias（如 alias cdu="composer update"），但通过 scripts 段可定义项目级命令别名，且能跨平台生效。这些命令会自动被 composer run（或旧版 composer run-script）识别。
在 composer.json 中添加：
"scripts": {
"du": "composer update",
"di": "composer install",
"dc": "composer clear-cache",
"test": "phpunit --colors=always",
"dev": [
"@du",
"@dc"
]
}
之后执行 composer run du 就等价于 composer update。注意：从 Composer 2.2 开始推荐用 composer run ，旧版需用 composer run-script 。
-
@xxx表示复用已有 script，适合组合操作（如"dev"同时跑更新和清缓存） - 脚本值可以是字符串（单条命令）或数组（多条顺序执行）
- 所有 script 命令默认在项目根目录执行，无需
cd - 若脚本含空格或特殊字符，建议用单引号包裹整个命令（如
'php -v | head -n1'）
用 bin 目录 + 可执行文件模拟全局别名
当需要真正像 shell alias 一样输入 cdu 就触发 composer update，可在项目根目录建 bin/ 并放可执行脚本，再把 bin/ 加入 $PATH（仅限当前项目生效）。
例如创建 bin/cdu：
#!/usr/bin/env bash cd "$(dirname "$0")/.." && composer update "$@"
然后 chmod +x bin/cdu，再运行 bin/cdu 即可。若想全局可用，需将 $(pwd)/bin 临时加到 PATH（如 export PATH="$(pwd)/bin:$PATH"）。
- 这种方式绕过 Composer 解析，可传参（
$@）、做条件判断、甚至调用其他工具 - Windows 用户需用
.bat或.ps1，且注意路径分隔符和权限问题 - Git 提交时建议忽略
bin/（除非是项目必需的 CLI 工具）
composer.json 的 bin 字段不适用于别名
别混淆：Composer 的 "bin" 字段（如 "bin": ["vendor/bin/phpunit"]）只用于声明「由依赖包提供的可执行文件」，Composer 安装后会软链进 vendor/bin/。它不能用来注册自定义命令别名。
常见误操作：
– 错误地写 "bin": ["cdu"] 并期望 cdu 命令生效
– 把 shell 脚本路径填进 bin 字段，结果 composer install 报错或无反应
-
bin字段只接受已存在的、有可执行权限的文件路径（相对composer.json） - 它不解释命令内容，也不支持内联脚本
- 如果真想让
cdu出现在vendor/bin/，必须先写好cdu文件并确保其在项目中存在，再填入bin字段
别名冲突与调试技巧
当多个 script 名称相同（比如不同依赖包都定义了 test），Composer 默认只执行你项目 composer.json 中定义的版本。但容易踩坑的是：某些 IDE 或终端插件会缓存 composer list 输出，导致新加的 script 不显示。
- 运行
composer run -l查看所有可用 script（含描述），确认是否加载成功 - 若报错
Script not found，检查拼写、是否漏了逗号、JSON 是否合法（可用composer validate） - 脚本中调用
php或git时，优先用绝对路径（如$(which php)）或确保环境变量一致 - CI 环境中，
composer run默认不启用交互模式，带--no-interaction的行为可能和本地不同
真正麻烦的是混合使用 scripts 和 shell alias：比如你在 .zshrc 里 alias 了 cdu，又在 composer.json 里定义了 du，两者逻辑不一致时，协作成员很容易搞混哪个才是“权威”操作。
