Composer global 命令安装工具类包到全局目录供 CLI 调用，不参与项目自动加载；项目内 require 安装运行时依赖到本地 vendor，写入 composer.json 并支持自动加载与版本锁定。
Composer 的 global 命令和项目内的 require 都是安装 PHP 包的方式，但作用范围、依赖管理逻辑和使用场景完全不同。
作用范围不同：全局 vs 本地
global 命令（如 composer global require laravel/installer）把包安装到 Composer 的全局 vendor 目录（通常是 ~/.composer/vendor/），所有项目都能调用其中的可执行命令（如 laravel new），但不会影响任何具体项目的 composer.json 或自动加载规则。
项目内 require（如 composer require monolog/monolog）只在当前项目根目录下生效，包被装进 vendor/ 子目录，同时写入当前项目的 composer.json 和 composer.lock，并参与该项目的自动加载和依赖解析。
依赖隔离与冲突处理方式不同
全局安装的包彼此之间不进行版本约束协调，Composer 不检查它们之间的依赖兼容性。如果两个全局工具依赖同一包的不同大版本（比如 A 要 guzzlehttp/guzzle:^7，B 要 ^8），就可能出问题，且没有简单办法隔离。
项目内 require 则严格遵循语义化版本和依赖图解析，Composer 会尝试找到满足所有要求的版本组合，并锁定到 composer.lock，保障可重现性。
自动加载和命令可用性有本质区别
全局包的二进制文件（bin）会被软链接到 ~/.composer/vendor/bin/，只要这个路径在系统 $PATH 中，就能直接运行（如 phpunit、laravel）。但它不会被项目自动加载——你不能在项目代码里 use 全局包的类。
项目内 require 的包默认启用 PSR-4/Autoload，类能被 require 或自动加载；它的 bin 文件（如有）默认只在项目 vendor/bin/ 下，需通过 ./vendor/bin/xxx 调用，或配合脚本配置。
什么时候该用哪个？
- 用 global：安装开发辅助工具，比如
phpunit（全局 CLI）、laravel/installer、deployer/deployer、psy/psysh—— 它们不参与业务逻辑，只提供命令行能力。 - 用 项目 require：引入实际参与运行的库，比如
guzzlehttp/guzzle、symfony/http-client、ramsey/uuid—— 这些要被你的代码new或use，且版本必须受控。 - 避免混用：不要用 global 安装项目运行时依赖；也不要用项目 require 安装通用 CLI 工具（除非你想为每个项目单独维护一份）。
本质上，global 是“给开发者用的工具箱”，项目 require 是“给应用用的零件库”。两者共存不冲突，但职责分明。
