cgr 不是 composer global require 的替代品，因其仅支持临时、隔离、一次性的包执行，不注册命令到 $PATH，也无法持久使用或管理。
不能直接用 cgr 替代 composer global require，它压根不提供“全局安装”能力——cgr 的设计目标是**临时、隔离、一次性的包执行**，和全局命令长期可用的逻辑完全相反。
为什么 cgr 不是 global require 的替代品？
cgr（Composer Global Runner）本质是绕过全局 vendor 目录，每次运行时：下载指定包 → 创建独立临时 vendor → 执行其二进制 → 清理。它不注册命令到 $PATH，也不写入 ~/.composer/vendor/bin/。
-
composer global require laravel/installer→ 之后能一直用laravel命令 -
cgr laravel/installer→ 只执行一次laravel new，结束后命令就不可用了 - 没有
cgr list或cgr uninstall，无法管理已“跑过”的包
想隔离全局包？用 composer create-project + alias 更靠谱
真正解决“全局命令污染+版本冲突”问题的路径，不是找 cgr 的替代，而是放弃全局安装本身。推荐组合：composer create-project 固定路径 + shell alias：
composer create-project --no-install --keep-vcs laravel/installer ~/.local/share/laravel-installer cd ~/.local/share/laravel-installer && composer install --no-dev
然后加到 shell 配置中：
alias laravel='php ~/.local/share/laravel-installer/bin/laravel'
- 所有依赖锁死在项目目录内，升级需手动
git pull && composer install - 不同版本可并存（如
~/.local/share/laravel-installer-4和-5） - 比
cgr多一次初始化成本，但换来的是可复现、可更新、可卸载
什么时候该坚持用 cgr？
只适用于那些你确定「这辈子就用这一次」的工具，比如临时生成一个 PHPStan 配置、跑一次 php-cs-fixer 修复旧项目、或者调试某个包的最新 dev-main 版本：
cgr phpstan/phpstan:1.10.x-dev -- --versioncgr friendsofphp/php-cs-fixer -- fix ./src --rules=@PHP80- 注意：必须显式指定版本（如
:^3.0），否则默认拉dev-main，可能失败 - 执行完立刻删掉临时目录（
cgr默认不清理，得自己rm -rf ~/.cgr）
真正难的不是选 cgr 还是 global require，而是承认：所谓“全局命令”，本身就是 Composer 设计上的权宜之计；长期项目里，每个 CLI 工具都应该有自己明确的生命周期和路径归属。
