Composer 不支持全局 vendor 目录，因 autoload.php 硬编码路径且 lock 文件依赖项目级安装路径，强行共享会导致类加载失败与版本冲突；正确做法是复用缓存、使用 --prefer-dist、抽离私有包或采用 monorepo。
Composer 本身不支持全局 vendor 目录，强行共享会导致依赖冲突、版本错乱和 autoload 失败——这不是配置问题，而是设计限制。
为什么不能直接共用一个全局 vendor 目录
Composer 的自动加载机制（vendor/autoload.php）是基于项目根目录生成的，它硬编码了包路径、命名空间映射和类文件位置。若多个项目指向同一 vendor，ClassLoader 会因路径冲突无法正确定位类，且 composer.lock 中记录的安装路径与实际不符，导致 composer install 反复重装或报错 Class not found。
- 每个项目必须有独立的
vendor目录，这是 Composer 的核心约束 -
COMPOSER_HOME控制的是缓存（~/.composer/cache），不是依赖安装目录 -
composer global require安装的是 CLI 工具（如laravel/installer），其vendor仅供全局命令使用，不可被项目引用
真正可行的“高效共享”方案：只共享下载缓存 + 合理复用已安装包
Composer 默认已启用本地缓存，但默认缓存仅保存 ZIP 包和 dist 文件。要提升多项目初始化速度，关键在于让 Composer 尽可能跳过下载和解压，复用已有的包源码副本。
- 启用
cache-dir并确保所有项目使用同一缓存路径（默认即为~/.composer/cache） - 设置
fxp/composer-asset-plugin或现代替代方案（如composer/installers）对特定类型包做符号链接（仅限开发环境，不推荐生产） - 更稳妥的做法：用
composer create-project --prefer-dist，强制走缓存 + ZIP 解压，比--prefer-source快 3–5 倍 - 检查缓存命中：运行
composer install -v，看到Downloading ... (cached)或Using version x.y.z from cache即生效
替代思路：用 symfony/flex 或 monorepo 工具管理跨项目公共代码
如果你的真实诉求是“避免重复维护通用组件”，那问题本质不是 Composer 共享，而是项目结构不合理。直接复用代码比复用 vendor 更可靠。
- 将公共逻辑抽成私有包，发布到私有 Packagist（如 Satis、Private Packagist）或 Git 仓库
- 在各项目中通过
"myorg/utils": "dev-main"引入，并启用repositories配置指向 Git URL - 搭配
composer config --global store-auths true管理私有仓库认证 - 若项目高度耦合，考虑用
git subtree或monorepo-builder统一管理，而非依赖层面共享
{
"repositories": [
{
"type": "vcs",
"url": "https://git.example.com/myorg/utils"
}
],
"require": {
"myorg/utils": "^2.1"
}
}
真正卡住效率的从来不是 vendor 目录大小，而是网络下载、PHP 编译、autoload 生成耗时。优化方向应聚焦缓存复用、dist 模式、私有包抽象——试图绕过 Composer 的项目隔离模型，只会引入更难排查的 autoload 错误和版本漂移。
