Composer 不支持跨项目共享 vendor，因其 autoload 映射、路径绑定、依赖求解均强耦合单项目 composer.json 和 composer.lock；硬链接或符号链接复用极易导致类加载失败、映射冲突和并发破坏，唯一可控方式是严格静态隔离且禁用所有修改命令。
Composer 本身不提供原子复用与共享操作能力，它没有“共享 vendor”或“多项目共用一份依赖”的设计机制；所谓“复用”，只能靠外部隔离+硬链接/符号链接+严格约束来模拟，且极易出错。
为什么 composer install 不支持跨项目共享 vendor
vendor 目录是 composer install 的专属输出产物，其结构（如 autoload.php、vendor/composer/autoload_*.php）强绑定当前项目的 composer.json 和 composer.lock。不同项目即使依赖相同包的同一版本，自动加载映射路径、类前缀、PSR-4 映射规则也可能不同——直接复用会导致 Class not found 或加载错类。
-
composer install过程中反复覆盖autoload.php，期间若被其他 PHP 进程加载，会触发Fatal error - 多个项目指向同一
vendor目录时，composer update或composer remove会破坏其他项目的依赖状态 - Composer 的 Solver 是基于单项目约束求解的，不感知“共享上下文”，无法校验跨项目依赖一致性
硬链接 vendor 是否可行？
在同文件系统下，对已安装完成的 vendor 目录做 ln -f -s 或 cp -al（硬链接目录需用 cp -al，但注意：Linux 上硬链接不能跨文件系统，且不能对目录使用 ln -d）看似节省空间，但存在严重风险：
- 任何项目执行
composer install --no-dev都会清空并重写整个vendor，影响所有链接方 -
composer dump-autoload会重生成全部 autoload 文件，破坏其他项目的映射逻辑 - PHP OPcache 可能缓存了旧的
autoload.php字节码，导致类加载行为不一致 - CI/CD 中并发部署多个项目时，
mv vendor切换过程若与另一项目正在require冲突，会直接报错退出
真正可控的“复用”只有一种方式：隔离 + 符号链接 + 禁写
仅适用于完全静态、绝不更新的场景（如只读镜像、函数计算冷启动优化），且必须满足三个前提：
- 所有项目使用**完全相同的
composer.lock文件内容**（哈希一致），包括平台配置（platform）、插件启用状态 - 所有项目
composer.json的autoload段完全一致（否则dump-autoload会产出不同映射） - 所有项目部署后**禁止执行任何会修改
vendor的命令**：禁用composer install、composer update、composer remove、composer dump-autoload
实操示例（假设统一 vendor 已构建在 /shared/vendor）：
cd /app/project-a rm -rf vendor ln -sf /shared/vendor vendor cd /app/project-b rm -rf vendor ln -sf /shared/vendor vendor
注意：/shared/vendor 必须由一次干净的 composer install --no-dev --optimize-autoloader --classmap-authoritative 生成，并通过 php -r "require 'vendor/autoload.php';" 验证可用性。
更安全的替代思路：用 Composer 插件或构建时注入
如果目标是减少重复下载和解压开销，应放弃“运行时共享 vendor”，转而利用 Composer 原生缓存机制：
- 全局设置
cache-dir到 SSD 路径，所有项目复用同一缓存池 - 用
composer install --download-only提前拉取包到缓存，再分发到各项目执行本地 install - 容器化部署时，在基础镜像中预装常用包（
composer global require不适用，应走vendor构建），再 COPY 到各应用层
真正的“原子性”只存在于单项目边界内；跨项目复用的本质是放弃 Composer 的状态管理权，把风险转移到运维侧——这点常被忽略，直到线上 Class not found 报警才暴露。
