不能直接同步 vendor 目录，因环境差异会导致二进制扩展失效、Class not found 等错误；正确做法是在服务器运行 composer install，确保 PHP 版本、扩展匹配，并上传 composer.json 和 composer.lock。
直接同步 vendor 目录是危险且不可靠的，别这么做。
为什么不能直接 rsync / scp vendor
本地和服务器的环境差异（PHP 版本、扩展、OS 架构、composer.json 锁定精度）会导致 vendor 中某些包的二进制扩展（如 ext-swoole、ext-protobuf）或平台相关依赖（如 symfony/flex 的脚本）直接失效。你看到的 Class not found 或 undefined symbol 错误，八成是这么来的。
-
composer.lock记录的是 hash 和版本，不是构建结果；不同机器上install出的vendor可能完全不同 - 本地开发可能用了
--dev，但线上不该装phpunit或laravel/pint -
vendor/bin下的可执行文件路径、shebang 行可能硬编码了本地 PHP 路径
正确做法：在服务器上运行 composer install
核心原则：让目标环境自己生成 vendor，而不是搬运。这要求服务器具备基础构建能力，但远比“同步失败后排查 2 小时”划算。
- 确保服务器已安装匹配的 PHP 版本和必要扩展（
openssl、mbstring、json等） - 上传
composer.json和composer.lock（必须一起传，缺一不可） - 用
composer install --no-dev --optimize-autoloader --no-interaction部署 - 如果服务器无法访问 packagist（比如内网），提前用
composer install --prefer-dist --no-dev在本地打包好vendor并上传——但这仍是妥协方案，只适用于完全隔离环境
常见卡点与绕过方式
部署时最常卡在权限、内存、网络三块，不是 Composer 本身的问题，而是执行环境没配好。
-
PHP Fatal error: Allowed memory size of XXX bytes exhausted→ 在命令前加php -d memory_limit=-1，或改php.ini -
Could not open input file: composer.phar→ 别用全局composer命令，下载最新composer.phar放项目根目录，用php composer.phar install -
file_put_contents(./composer.lock): failed to open stream: Permission denied→ 检查当前用户对composer.lock所在目录是否有写权限，别用root运行，也别让 web 用户拥有写权限 - 国内服务器拉包慢 → 配置镜像源：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意该镜像已停，换https://mirrors.aliyun.com/composer/）
真正麻烦的从来不是命令怎么敲，而是搞不清哪台机器该装什么扩展、composer.lock 是否被意外修改、以及上线前忘了清空 bootstrap/cache/config.php 这类缓存——这些细节不写进部署脚本，早晚出事。
