composer全局工具版本无法精确锁定，因global require不生成lock文件、不降级、不覆盖旧二进制，且path优先级和php版本冲突易致失效；正确做法是手动进入~/.composer执行require--no-update+rm-rf vendor+install，或用create-project隔离安装并显式绑定php版本。
全局工具版本无法靠 composer global require 精确锁定 —— 它默认只写 composer.json 的 require，不生成 composer.lock，也不校验已安装包的版本一致性。
为什么 composer global require foo/bar:1.2.3 之后运行还是旧版本？
Composer 全局安装本质是把包装进 ~/.composer/vendor/，但执行时靠的是 ~/.composer/vendor/bin/ 下的可执行文件软链。问题常出在：
-
foo/bar已存在且版本更高（比如 2.0.0），global require不会降级，也不会覆盖已有二进制 -
~/.composer/vendor/bin/在$PATH中位置靠后，系统优先找到其他路径下的同名命令（如 Homebrew 装的） - 没运行
composer global update，旧依赖树未刷新，新require可能被忽略
强制指定并固化全局工具版本的正确流程
必须绕过“仅 require”的惯性操作，手动触发锁文件生成和重装：
- 进入全局 vendor 目录：
cd ~/.composer - 初始化或确认存在
composer.json（若无则composer init -n） - 用
--no-update添加精确版本：composer require foo/bar:^1.2.3 --no-update - 清除现有安装：
rm -rf vendor/ - 完整重装并生成 lock：
composer install
这一步确保 composer.lock 生效，且所有依赖按锁定版本解析，不是“最新兼容版”。
不同 PHP 版本下全局工具冲突怎么办？
Composer 全局没有 PHP 版本隔离机制。如果项目需 PHP 8.1 的 phpstan，而本地 CLI 是 PHP 7.4，直接 global require 会因依赖约束失败或装错版本。
- 改用
composer create-project独立安装：composer create-project phpstan/phpstan:1.10.3 ~/tools/phpstan-1.10.3 - 为该工具建专用 wrapper 脚本，显式调用对应 PHP：
#!/bin/bash /usr/local/bin/php81 ~/tools/phpstan-1.10.3/bin/phpstan "$@" - 避免混用
global和项目内require-dev同一工具 —— 二者生命周期、更新节奏、PHP 环境完全不可控
真正稳定的全局工具管理，核心是放弃“全局即便利”的假设：lock 文件要手动触发，PHP 版本要显式绑定，二进制路径要逐个验证。省掉其中任何一环，第二天就可能发现 phpcbf 报错说找不到 SlevomatCodingStandard —— 其实只是它悄悄升级到了不兼容的 9.x。
