composer install 能加速多项目部署，因为它跳过依赖解析，仅读 lock 文件、查全局 cache、解压 zip；只要版本一致且 cache 有效（默认 --prefer-dist），就复用 dist 包，不联网不重算。
composer install 本身不负责跨项目复用，真正起作用的是它的底层依赖——全局 cache 和 lock 文件的确定性还原能力。 它不是“让多个项目共享 vendor 目录”，而是通过复用 dist 包 + 精确版本锁定，避免重复下载和解压，间接实现高效复用。
为什么 composer install 能加速多项目部署
它跳过所有依赖解析，只做三件事：读 composer.lock、查本地 ~/.composer/cache/、解压对应 zip。只要两个项目用了同一个包的相同版本（比如 monolog/monolog v2.13.0），composer install 就直接从 cache 复制，不走网络、不重算。
- 确认 cache 是否生效：运行
composer config --global cache-dir，看该路径下是否有大量.zip文件且磁盘占用随 install 增长 - 必须用
--prefer-dist（默认行为），否则会走--prefer-source，每次 clone git repo，完全无法复用 - 不同 PHP 版本或平台（如 Windows/macOS）不影响 cache 复用，因为 dist 包是预打包的归档，与运行环境无关
跨项目复用失败的常见原因
不是 composer install 有问题，而是 lock 文件或环境配置破坏了复用前提。
-
composer.lock里记录的包版本不一致：A 项目锁的是symfony/consolev5.4.32，B 项目是 v6.4.0 → cache 不命中，各自下载 - 全局 cache 被清空或权限异常：比如 CI 环境每次跑完都
rm -rf ~/.composer/cache，复用失效 - 用了
--no-cache或COMPOSER_CACHE_DIR指向空目录 → 强制绕过 cache - 项目启用了
platform-check或自定义repositories，导致 Composer 放弃 cache 查找逻辑
如何验证一个包是否被多个项目真正复用
别只看 vendor 目录大小，要追踪实际 I/O 行为。
- 加
-vvv参数运行composer install，搜Downloading关键字：如果没出现，说明走了 cache；如果出现，说明没命中 - 检查 cache 目录下对应包的 zip 修改时间：
ls -la ~/.composer/cache/files/monolog/monolog/，多个项目 install 后时间戳不变，就是复用了 - 对比两次 install 的耗时：首次可能 30 秒，第二次若稳定在 2–3 秒，基本可判定 cache 生效
真正容易被忽略的点是：cache 复用只发生在 dist 包层面，跟 vendor/ 目录完全无关。你删掉某个项目的 vendor 再 install，只要 lock 没变、cache 没清，它就还是秒装——但如果你手动改了 composer.json 又没 run require 或 update，install 会彻底无视那行改动，看似“没装上”，其实是设计使然。
