vendor目录不能直接跨项目复制，因为Composer会校验composer.lock中的哈希值、依赖树结构、PHP平台约束及扩展要求；即使包名版本相同，PHP版本或autoload配置差异也会触发重新下载和生成。
为什么 vendor 目录不能直接跨项目复制
直接把一个项目的 vendor 复制到另一个项目里，看似能跳过安装，但大概率会失败。Composer 不只看文件是否存在，还会校验 composer.lock 中记录的哈希值、依赖树结构、PHP 平台约束（如 php: >=8.1）以及扩展要求（如 ext-curl）。哪怕两个项目 require 的包名和版本完全一样，只要 PHP 版本不同或 composer.json 中的 autoload 配置有差异，composer install 就会重新下载并生成新 autoload 文件。
如何复用 Composer 缓存加速多项目安装
Composer 本地缓存才是真正的共享枢纽——它不绑定具体项目，而是按包名+版本+dist/source 类型索引。只要缓存存在，所有项目执行 composer install 或 composer require 时都会优先复用。
- 确认缓存位置：
composer config --global cache-dir（通常是~/.composer/cache） - 清理失效缓存：
composer clear-cache，尤其在升级 PHP 或切换镜像后 - 避免手动删缓存目录：可能破坏内部索引，用命令更安全
- CI/CD 中可挂载该目录为持久卷，让多个构建作业共享同一份缓存
composer install --prefer-dist 和 --no-dev 的实际效果
--prefer-dist 强制走压缩包（.zip/.tar.gz）而非 git clone，对大多数包意味着更快下载和更少磁盘 I/O；--no-dev 则跳过 require-dev 下的所有包（如 phpunit/phpunit、laravel/pint），通常减少 30%~50% 的依赖数量。
- 开发环境慎用
--no-dev：会导致测试、代码格式化等工具缺失 - 生产部署必须加
--no-dev，否则可能意外加载开发专用类 -
--prefer-dist在国内镜像下效果更明显，因为 dist 包已预编译，无需再解包+install - 二者可组合使用：
composer install --prefer-dist --no-dev --optimize-autoloader
为什么 composer update 比 install 慢得多
composer install 是“照单发货”：读 composer.lock，校验哈希，解压缓存里的包，生成 autoload 映射——全程无网络解析。而 composer update 是“重新算账”：要连 Packagist（或镜像）拉最新元数据、递归求解整个依赖图、比对版本约束、尝试回溯兼容路径，内存占用高、CPU 跑满是常态。
- 日常开发尽量避免
composer update，改用composer update vendor/package --with-dependencies精准更新 - CI 流水线中应固定用
composer install，确保构建可重现 - 若必须 update，先
composer self-update升级到 Composer 2.7+，其 SAT 求解器比 1.x 快 3~5 倍
缓存复用和命令参数控制是见效最快的优化点，但容易被忽略的是：每次 composer install 后是否真的需要重生成 autoload？如果只是部署，--no-scripts 可跳过 post-install-cmd，省掉几秒到十几秒不等。
