Composer无内置别名机制，可靠方案仅两种：shell函数（全局，需用"$@"透传参数并写入~/.zshrc）和composer.json的scripts（项目级，官方支持，需注意命名、调用语法及执行条件）。
Composer 本身不提供命令别名机制，composer alias 或 composer config --global alias.cu update 这类写法根本不存在，所有“别名”都是靠外部手段模拟出来的。真正在项目中可用、可维护、可协作的方案只有两种：shell 函数（全局）和 scripts（项目级）。
用 shell 函数实现带参数的全局快捷命令
alias 不支持透传参数，比如 alias cu="composer update" 后执行 cu guzzlehttp/guzzle 会失败或静默忽略参数。必须改用函数才能安全保留引号、空格和任意参数结构。
-
cu(){ composer update "$@"; } ——"$@"是关键，它原样传递所有参数，包括cu "laravel/framework:^11.0"这种带空格和版本约束的写法 - 函数要写进
~/.zshrc（macOS/Linux 默认）或~/.bashrc，然后运行source ~/.zshrc生效 - 避免命名冲突：别用
ci（GNU coreutils 命令）、cs（可能被其他工具占用），推荐加前缀如cupdate、cinstall - Windows 用户若用 WSL，同样适用；原生 CMD/PowerShell 不支持该语法，需切换到 WSL 或改用批处理封装
在 composer.json 的 scripts 中定义项目级快捷命令
scripts 是 Composer 官方唯一支持的脚本封装方式，适合团队统一操作、CI/CD 集成、与代码版本共管。它不是“别名”，而是可执行的命令绑定，名称必须严格匹配，大小写敏感，不模糊补全。
- 脚本必须定义在
composer.json根层级的"scripts"字段下，不能嵌套在extra或其他块里 - 定义示例：
"dev-start": "php -S localhost:8000 -t public"，之后用composer dev-start或composer run dev-start调用 - 多条命令建议用数组写法：
"refresh": ["@clear-cache", "composer install --no-interaction"]，便于拆分维护 - 调用时传参必须用双
--分隔，例如composer test -- --filter=MyTest，否则参数会被 Composer 自身解析掉 - 脚本值是 PHP 文件路径时（如
"deploy": "php scripts/deploy.php"），务必在 PHP 文件开头显式加载 autoloader：require __DIR__ . '/vendor/autoload.php';
常见错误：脚本写了却没执行？
脚本配置看似正确但完全不触发，通常卡在几个硬性条件上：
-
post-install-cmd并非每次composer install都执行——只有当composer.lock缺失或与composer.json不一致导致重生成时才触发；稳定触发请用post-update-cmd或手动composer run - 脚本名拼错：大小写、短横线（
-）、下划线（_）都算不同命令，composer run devstart≠composer run dev-start - Windows 下含短横线的脚本名必须加双引号：
composer run "dev-start"，否则报 Script not found - 脚本中调用
php artisan或npm run build时，PATH 可能不含对应二进制，或权限不足（如artisan没有 +x 权限），应改用php artisan显式调用 - 用
composer install --no-scripts会跳过所有脚本，生产部署时若加了这个参数，post-install-cmd就不会跑
真正难的不是写一行脚本，而是判断该用 shell 函数还是 scripts：前者解决你个人终端效率，后者解决团队行为一致性。别把 scripts 当成“别名”来记，它本质是项目契约的一部分——删掉一个 clear-cache 脚本，可能让新同事在本地启动服务时卡在旧缓存里一小时。
