不会直接污染本地项目，但会破坏隔离性——global update 升级全局工具链（如laravel/installer、phpunit/phpunit），与项目vendor无关；若项目require-dev同名包且未锁版本，后续composer update可能因解析器变化间接影响依赖树。

global update 会污染本地项目吗？

不会直接污染，但会破坏隔离性——composer global update 升级的是全局 Composer 工具链和全局安装的包（如 laravel/installer、phpunit/phpunit），它们与项目 vendor/ 无关；但如果你在项目里通过 require-dev 引入了同名全局工具（比如 phpunit/phpunit），而本地 composer.json 又没锁死版本，global update 不会动它，但后续 composer update 可能因解析器行为变化间接影响依赖树。

如何验证 global 和 local 是否真正隔离

关键不是“有没有装”，而是“运行时加载谁”。以下三步可实锤验证：

• 执行 composer global list 记下已安装的全局包及其版本（如 phpunit/phpunit 10.5.1）
• 进入项目目录，运行 composer show phpunit/phpunit —— 若输出为空，说明未被本地 require；若存在，看版本是否与 global 一致（通常不一致，除非你刻意 require-dev 了相同版本）
• 检查 vendor/bin/phpunit 的实际入口：运行 head -n 1 vendor/bin/phpunit，确认它指向 ../phpunit/phpunit/phpunit 而非全局 bin 目录；再运行 which phpunit 对比路径

CI 流程中 global update 的风险点

CI 脚本里写 composer global update 是高危操作，原因很具体：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 它可能升级 composer/composer 自身（如从 2.9.6 升到 2.10.0），而新版本的 SAT 求解算法或 lock 文件格式变更，会导致同一 composer.lock 在不同 Composer 版本下解析出不同依赖树
• 某些全局插件（如 hirak/prestissimo）已被废弃，global update 可能强行拉入不兼容版本，干扰 composer install 的下载行为
• CI 镜像若复用全局缓存（~/.composer/cache），而该缓存曾被旧版 Composer 写入损坏数据，global update 不清理它，反而让问题延续

替代方案：用 project-local 工具链代替 global

真正安全的做法是把工具收进项目自身依赖，而非靠 global 管理：

• 用 composer require --dev phpunit/phpunit:^10 替代 composer global require phpunit/phpunit，确保版本受 composer.lock 控制
• 脚本中调用 vendor/bin/phpunit 而非裸命令 phpunit，避免意外命中全局版本
• CI 中禁用全局命令：在构建前加 export PATH="$(pwd)/vendor/bin:$PATH"，让 phpunit 命令优先走本地
• 若必须用全局工具（如 deployer/deployer），改用 curl -sS https://getcomposer.org/installer | php -- --filename=composer 下载独立二进制，不依赖 global 状态

global update 的最大陷阱在于：它看似只改自己，实则悄悄改了 Composer 的求解上下文。真正隔离不是靠“不碰 vendor”，而是让所有可变因素（工具版本、插件、缓存）都显式声明、可追踪、可重建。