预置 vendor 目录不可直接用于生产部署，因其与 PHP 环境强绑定，跨机器、架构或主版本易失效；真加速应通过 composer install 配合镜像、缓存、--prefer-dist 等参数优化实现。
预置包（pre-installed vendor）不能直接用于生产部署——它和当前 PHP 环境强绑定，跨机器、跨架构、跨 PHP 主版本都可能失效。真正能“快速部署”的不是拷 vendor 目录，而是用 composer install 在目标环境里重装，配合镜像、缓存和参数优化来提速。
为什么 vendor 目录不能 rsync 或 tar 过去
看似省事，实则埋雷：
-
vendor/里含编译扩展（如ext-redis）、生成代码（Doctrine Proxy 类）、平台相关二进制（vendor/bin/php-cs-fixer），换环境大概率Class not found或undefined symbol - 不同 PHP 版本下，
autoload_static.php生成的类映射结构不兼容；PHP 8.1 和 8.2 的 opcache 字节码也不能共用 -
composer.lock记录的是 dist 包哈希，但你传过去的 vendor 是源码形态（或混合形态），校验失败后 Composer 可能静默重建，反而更慢
怎么让 composer install 快起来（真加速）
核心是减少网络 I/O 和文件操作，不是跳过安装：
- 全局配置阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 启用并行下载（Composer 2.2+）：
composer config -g parallel-downloads 10 - 强制走 dist 包（zip/tar.gz）：
composer config -g prefer-dist true，避免 git clone - CI/CD 中挂载 Composer 缓存目录：
~/.composer/cache到 runner 卷，复用已下载的 zip 包 - 部署命令加
--prefer-dist --no-autoloader --no-scripts：跳过 autoload 生成和脚本执行，等安装完再单独跑dump-autoload
预置包唯一安全用法：构建时缓存 vendor
不是把 vendor 当资产分发，而是把它当 CI 构建中间产物来复用：
- Docker 构建中，把
composer install --no-dev --prefer-dist放在独立 layer，利用 Docker cache 加速后续构建 - GitHub Actions 中用
actions/cache缓存vendor/目录（注意 key 要包含 PHP 版本、Composer lock hash、OS 架构） - 缓存前必须清理危险内容：
rm -rf vendor/bin/ vendor/**/tests/ vendor/**/.git vendor/composer/installed.json - 缓存后仍需在容器启动时验证：
composer show --dev应报错，ls vendor/bin/应为空
别碰 --no-autoloader + 手动 dump 的组合
这个组合容易出错，且收益极小：
-
composer install --no-autoloader会跳过autoload_classmap.php生成，但dump-autoload --optimize --classmap-authoritative必须基于已安装的包路径运行；路径不对，classmap 就漏类 - 如果先删了
vendor/**/tests/再 dump，而 autoload-dev 里还注册着"Tests": "tests/"，classmap 会把测试类也扫进去，白忙一场 - 真正该做的，是在
install阶段就用全参数一气呵成：composer install --no-dev --optimize-autoloader --classmap-authoritative --no-interaction --prefer-dist
快的前提是稳——所有加速手段都建立在 lock 文件干净、PHP 环境一致、参数不缺位的基础上。少一个 --classmap-authoritative，autoload 就可能退化回反复 stat()，慢几倍；少清一次 vendor/bin/，就多一个可被路径遍历触发的 phpunit 入口。
