生产环境不应直接运行 composer install，因其会引入开发依赖、未锁定版本和本地 autoloader，带来安全、性能与一致性风险；应改用构建阶段预装依赖并部署完整 vendor 目录。
直接在服务器上运行 composer install 是可行的，但绝大多数生产环境不该这么做。
为什么不能在服务器上直接跑 composer install
因为这会把开发期依赖（比如 phpunit、larastan）、未锁定的版本（dev-main 或 ^2.0）和本地生成的 autoloader 一起带进生产环境，带来安全、性能和一致性风险。
- 服务器通常没装 Composer，或版本老旧（如 CentOS 自带的
php-composer包常是 1.x） -
composer install需要写入vendor/和生成autoload_*.php，而生产机往往禁止写入 webroot 目录 - 如果
composer.lock里含平台配置（如ext-redis），但服务器缺扩展，安装会中断且报错模糊（常见：Your requirements could not be resolved）
composer install --no-dev --optimize-autoloader --no-interaction 的实际效果
这条命令是“能跑起来”的底线，但不是推荐做法——它只解决部分问题，掩盖更多隐患。
-
--no-dev确实跳过require-dev，但不会清理已存在的vendor/下的 dev 包（比如上次手动装过phpunit，这次不会删） -
--optimize-autoloader生成 classmap，加快加载，但若项目含大量 PSR-4 自动发现（如 Laravel 的app/），反而让首次部署变慢 -
--no-interaction避免卡住，但也会吞掉关键提示，比如「某包需要 ext-gd，当前 PHP 不支持」——你只会看到失败退出，没具体错误
示例错误场景：PHP Fatal error: Uncaught Error: Call to undefined function mb_strlen() —— 实际是 symfony/polyfill-mbstring 没生效，因为 ext-mbstring 缺失，而 Composer 没报这个依赖冲突。
真正该做的：构建阶段预装 + 部署只同步代码和 vendor
把依赖安装从服务器剥离，挪到 CI 或本地构建机上，才是稳定路径。
- 构建机用和生产一致的 PHP 版本（如
php:8.2-cli-slimDocker 镜像），执行composer install --no-dev --optimize-autoloader - 打包时包含
vendor/和composer.lock，但排除node_modules/、.git/、tests/ - 部署脚本只做 rsync / scp / git pull + 权限修复（
chown -R www-data:www-data vendor/），不碰 Composer - 若必须热更新，改用
composer install --no-dev --no-scripts --classmap-authoritative，禁用 post-install-cmd（避免执行php artisan optimize这类可能出错的操作）
最常被忽略的一点：服务器上的 memory_limit。即使加了 --optimize-autoloader，Composer 在解析几百个包时仍可能因内存超限静默失败，错误日志里只留一句 Killed。别信默认值，部署前先确认 php -r "echo ini_get('memory_limit');" 至少是 512M。
