不能直接在目标服务器运行composer install，因生产环境常无php/composer或权限受限；vendor目录必须与本地完全一致，否则autoload失效导致class not found；须用composer install –no-dev –optimize-autoloader并基于锁定文件部署。
为什么不能直接在目标服务器上运行 composer install
因为很多生产环境（尤其是老旧或受限的共享主机、某些docker基础镜像、CI/CD构建后只读容器）压根没装PHP或composer，甚至不允许执行php命令。硬要装，会引入权限、版本、扩展依赖（如zlib、openssl）等一连串连锁问题——不是不能，是不稳、不可控、难复现。
vendor目录必须和本地开发完全一致吗？
必须。Composer的自动加载逻辑（vendor/autoload.php）、类名映射、PSR-4路径、甚至composer.lock里记录的哈希值，都严格绑定于vendor/下每个包的精确版本与文件结构。哪怕少一个.gitignore或错一个autoload_static.php生成时间戳，都可能导致Class not found或require(): failed to open stream。
-
composer install --no-dev --optimize-autoloader是必须加的，否则vendor/里会多出测试工具、文档、未压缩的源码，体积大且可能触发生产环境禁止的扩展 - 确保本地PHP版本 ≥ 目标服务器PHP版本，否则
opcache.preload或match表达式等语法可能让vendor/里的代码直接报Parse Error - 别用
composer update生成vendor/——必须基于已提交的composer.lock执行install，否则部署时版本漂移无法追溯
怎么把vendor/安全打包进部署包？
关键不是“打包”，而是“剔除不该上线的东西”。直接tar -czf deploy.tgz .会带上node_modules、.git、tests/、docker-compose.yml这些干扰项，增大体积还可能泄露敏感配置。
- 用
rsync -av --exclude='node_modules' --exclude='.git' --exclude='tests/' --exclude='phpunit.xml' ./ user@server:/var/www/app/比scp更可控 - 如果走CI/CD，推荐在构建阶段用
composer install --no-dev --optimize-autoloader --no-scripts，再用find vendor/ -name '*.md' -delete删掉所有README（节省几百KB，避免被扫描器误读） -
vendor/bin/下的二进制（如phpunit、phinx）除非线上真要跑迁移，否则一律删掉：rm -rf vendor/bin/
部署后发现Class not found但vendor/明明存在？
大概率是自动加载缓存没生效或路径不对。Composer生成的vendor/autoload.php本身不包含逻辑，它只是引导到vendor/composer/autoload_*.php这些真实映射文件——而这些文件依赖vendor/composer/autoload_classmap.php等静态结构，一旦你手动改过composer.json autoload 配置但没重跑install，或者用了dump-autoload --classmap-authoritative却漏了--no-dev，就会断链。
- 检查
vendor/composer/autoload_static.php里$classMap数组是否为空——空就说明autoload配置写错了或没生效 - 确认你的入口脚本（如
public/index.php）里require __DIR__.'/../vendor/autoload.php';路径正确，别用dirname(__FILE__)这种易受chdir()影响的写法 - 如果用了APCu或OPcache，部署后记得
opcache_reset()或清APCu缓存，否则旧的类映射还在内存里
预构建vendor听着简单，但真正卡住人的永远是“本地能跑”和“线上报错”之间那几行被忽略的autoload细节、PHP小版本差异、还有删不干净的开发残留。盯住composer.lock、autoload.php、opcache这三处，比反复打包重试快得多。