生产环境严禁运行composer update，必须严格使用composer install --no-dev --optimize-autoloader --classmap-authoritative并依赖开发侧提交的composer.lock；批量升级指在CI中统一决策、测试、生成并推送lock文件至所有项目，而非生产端操作。
生产环境不能批量升级项目依赖——这不是操作问题，而是约束问题。Composer 的 composer update 本质是重新求解依赖图，而生产环境必须严格遵循 composer.lock 中记录的精确版本。所谓“统一升级”，只能发生在开发侧完成决策、测试、验证后，再将新 composer.lock 推送至所有生产实例。
为什么不能在生产环境跑 composer update
直接在生产服务器上执行 composer update（哪怕加了 --no-dev）会破坏部署一致性：
- 它修改
composer.lock，而该文件本应由开发人员控制并提交到 Git；CI/CD 流水线若未同步该变更，下次构建将拉取旧 lock，导致行为漂移 - 不同服务器可能因缓存、PHP 版本微差或扩展缺失，求解出不同结果，出现“这台机器能跑，那台报 Class not found”
- 没有
--dry-run预览机制，无法提前确认是否引入了已知 CVE 或不兼容子依赖（如psr/http-clientv2 不兼容旧代码）
真正可行的“批量升级”流程
所谓“批量”，是指对多个项目（如 20 个 Laravel 微服务）执行同一套升级策略，而非单个项目内一键全升。关键动作都在开发/CI 环节：
- 用
composer outdated --direct --format=json批量扫描所有项目，提取需升级的包名与当前/候选版本 - 编写脚本遍历各项目目录，对目标包执行
composer update vendor/package-name:^x.y --with-dependencies，并自动提交composer.lock - 每个项目升级后必须通过自动化测试门禁（PHPUnit + Pest + 自定义健康检查端点），失败则中止后续项目
- CI 流程中禁止
composer update出现在任何部署脚本里；生产部署命令只能是composer install --no-dev --optimize-autoloader --classmap-authoritative
升级后类找不到？先别怀疑 autoload
生产环境部署后报 Class not found，90% 不是 autoloader 问题，而是：
-
--classmap-authoritative生效后，未被 classmap 扫描到的类（如运行时拼接的类名、匿名类、未声明在autoload或autoload-dev中的测试辅助类）直接失败，不会 fallback - 框架缓存未清：Laravel 必须跟
php artisan config:clear && php artisan view:clear，否则旧缓存可能引用已删除的类路径 - opcache 预加载（
opcache.preload）文件里调用了class_exists()或new，导致 FPM 启动失败，但错误日志常被忽略
全局工具链也得“批量管”
团队共用的全局包（如 laravel/installer、deployer/deployer）不能靠 composer global update 统一升级——它不保证兼容性，且容易因 PHP 版本或互斥依赖中断：
- 改用项目级安装：
composer require --dev deployer/deployer，并通过scripts定义"dep": "vendor/bin/dep"统一调用入口 - 若必须全局维护，用脚本逐个检查：
composer global show vendor/package | grep -E 'versions|latest'，再显式composer global require vendor/package:^7.0 - 定期清理：对长期无更新、无 issue、README 明确弃用全局安装的包（如
phpstan/phpstan），执行composer global remove vendor/package
真正的批量升级，是把升级决策、测试验证、lock 文件生成全部收口到 CI，并让所有生产实例只认一个 lock 快照。任何绕过这层控制的“快捷方式”，最终都会变成线上事故的定时器。
