composer 没有 composer global update 命令；全局包更新只能通过 composer global require 或进入 ~/.composer 目录执行 composer update，且全局依赖由独立的 ~/.composer/composer.lock 管理，与项目 lock 文件无关。
全局包更新不会写入任何项目级 lock 文件，局部包更新必须依赖 composer.lock 才能复现；两者根本不在同一套版本控制体系里。
composer global update 为什么根本不存在
Composer 没有 composer global update 这个命令。所谓“更新全局包”，实际只有两种操作：
-
composer global require vendor/package：安装或升级指定包到最新稳定版（等价于加--update-with-dependencies） -
composer global update vendor/package：这是错误用法，会报错Command "global" is not defined—— 因为global是子命令前缀，不是独立上下文
真正可行的路径只有一条：cd ~/.composer && composer update vendor/package，但这手动跳进全局配置目录的操作极易出错，且绕过了 Composer 对全局环境的封装逻辑。更稳妥的做法是先卸载再重装：composer global remove vendor/package && composer global require vendor/package。
全局包不生成 composer.lock，也没法被项目 lock 文件约束
全局包安装在 ~/.composer/vendor/ 下，其依赖关系由 ~/.composer/composer.json 和 ~/.composer/composer.lock 管理 —— 注意，这是**全局专属的 lock 文件**，和你当前项目的 composer.lock 完全无关。
- 项目运行时不会读取全局
composer.lock，它只影响composer global命令的行为 - CI/CD 流水线中若用了全局包（如
php-cs-fixer），必须显式声明版本：composer global require friendsofphp/php-cs-fixer:^3.14，否则下次global require可能拉到破坏性更新 - 无法用项目级
composer install --no-dev控制全局包，它们压根不在同一个依赖图里
局部包更新后，全局包仍可能干扰自动加载
当项目依赖和全局工具共用同一类库（比如都用 symfony/console），而版本不一致时，容易触发 Class not found 或方法不存在错误，尤其在 Laravel artisan 命令中。
- 原因：PHP 的
include_path或autoload.php加载顺序可能导致全局 vendor 下的类先被加载 - 验证方式：运行
composer dump-autoload -o后，检查vendor/composer/autoload_classmap.php是否混入了全局路径 - 解决办法：确保项目
composer.json中的autoload配置不依赖全局安装的包；必要时加--classmap-authoritative强制只走 classmap，排除动态查找干扰
想让全局工具版本可追溯？只能靠人工快照
Composer 不提供全局环境的版本快照导出功能。如果你需要在团队中同步全局工具链（例如统一用 phpunit 10.5、psalm 5.22），不能依赖 composer global install，而得做两件事：
- 维护一个纯文本清单，比如
global-tools.txt，每行写friendsofphp/php-cs-fixer:^3.14 - 用 shell 脚本批量执行：
cat global-tools.txt | xargs -I {} composer global require {} --no-interaction
这比幻想“全局 lock 文件”更可靠 —— 因为全局配置本身就不参与项目构建生命周期，强行把它塞进 CI 流程，只会让问题更难定位。
