生产环境执行 composer install 必须加 –no-dev 参数，否则会安装 require-dev 中的开发依赖，导致 class not found 等错误；应配合 –optimize-autoloader 在 ci 或本地构建后打包 vendor/ 部署。
composer install 为什么在生产环境报错 “require-dev”？
因为默认 composer install 会装 require-dev 里的包，比如 phpunit、laravel/pint，这些在生产服务器上不仅没用，还可能引发权限、扩展缺失或内存溢出问题。
- 必须加
--no-dev参数：composer install --no-dev --optimize-autoloader -
--optimize-autoloader生成静态类映射，减少文件系统查找，对性能有实际提升 - 如果之前本地跑过
composer update，记得先git add composer.lock—— 生产环境必须依赖composer.lock，不能只靠composer.json - 常见错误现象：
Class 'TestsTestCase' not found或vendor/bin/phpunit: not found，基本就是漏了--no-dev
要不要在生产机上运行 composer install？
不推荐。生产服务器通常没装 composer，也不该开放写权限给 web 用户；更关键的是，它会触发 autoload 重生成、脚本执行（如 post-autoload-dump），容易暴露路径或触发意外逻辑。
- 最佳实践：在 CI 或本地干净环境中执行
composer install --no-dev --optimize-autoloader，把整个vendor/打包上传 - 若必须在线安装，确保
COMPOSER_HOME指向可写目录，且 PHP 内存限制 ≥ 1.5G（memory_limit=1536M） - 注意
config.platform设置：比如本地是 PHP 8.2，但生产是 8.1，就得在composer.json里显式设"platform": {"php": "8.1"}，否则install可能拉错版本
APP_ENV=production 还是 APP_DEBUG=true 会影响 composer 吗？
完全不影响。Composer 不读 Laravel 的 .env，它只认 composer.json 和锁文件。但这两个变量会影响后续 Laravel 启动行为，间接暴露 composer 安装是否干净。
- 典型连带问题：如果漏了
--no-dev，而APP_DEBUG=true，Laravel 可能尝试加载vendor/autoload-dev.php，直接 500 报错 -
APP_ENV=production会禁用调试工具栏，但不会跳过异常堆栈——所以装错依赖时，你看到的仍是清晰的Class not found，不是“页面空白” - 真正要检查的是
bootstrap/autoload.php是否引用了vendor/autoload.php（标准 Laravel 都是），而不是 dev 版本
vendor 目录上传还是忽略？Git 忽略但部署要保留
vendor/ 必须进部署包，但绝不能进 Git。这是最容易混淆的一点：很多人以为 “Git 忽略 vendor” 就等于 “部署时也别管它”，结果上线后直接 ClassNotFound。
- 确认
.gitignore里有/vendor，且没被git add -f强行提交过 - 部署脚本中，要么 rsync 整个
vendor/，要么用tar -cf app.tar . --exclude=node_modules --exclude=.git打包（别漏composer.lock） - 如果用 Capistrano / Envoyer / Laravel Envoy，它们默认不传
vendor/，得手动加rsync_options: '--include="vendor/**"'类配置 - 一个硬指标：部署后执行
php artisan tinker能进交互界面，且app()->environment()返回"production"，说明 autoloader 和环境都对了
真正的麻烦往往不在命令本身，而在 lock 文件和 vendor 目录的生命周期管理——它们必须严格绑定，差一个哈希值，就可能引入不兼容的 patch 版本。