CI 中不该用 composer update 更新共享依赖，因其会忽略 composer.lock、重算依赖图并破坏构建可重现性；应由开发者在本地执行受控的 composer update 并提交新 lock 文件，CI 仅运行 composer install。
CI 中不该用 composer update 更新共享依赖
持续集成环境里运行 composer update 是高风险操作，它会忽略 composer.lock、重算整个依赖图、生成新 lock 文件——这直接破坏构建可重现性。所有稳定 CI 流水线（GitHub Actions、GitLab CI 等）都应禁用该命令，除非你明确在做依赖审计或安全修复。
真正该做的：用 composer install + 缓存 + lock 文件校验
共享依赖的“更新”不是在 CI 里发生的，而是在开发阶段由人主动触发并提交新 composer.lock 后，CI 才被动安装。关键动作都在 Git 提交前：
- 开发者本地运行
composer outdated --direct查看哪些显式依赖有新版，特别注意带[security]或主版本跳变（如symfony/console 5.4 → 6.4）的条目 - 确认升级意图后，执行
composer update vendor/a vendor/b --with-dependencies（不加引号、写全包名），避免子依赖卡旧版 - 提交更新后的
composer.lock—— 这才是 CI 能感知到的“共享依赖更新” - CI 脚本只需跑
composer install --no-interaction --prefer-dist，再配合缓存~/.composer/cache目录即可秒级完成
如果真要 CI 自动升（比如安全兜底），必须加严格约束
极少数场景（如 nightly 安全扫描）需 CI 主动升级，但必须规避全量重算风险：
- 只升已知存在漏洞的包：
composer update guzzlehttp/guzzle --with-all-dependencies，且命令前加composer outdated | grep -q "guzzlehttp/guzzle.*\[security\]" || exit 0做守卫 - 禁止使用
composer update无参数形式，也禁用--no-dev这类模糊开关——它仍会更新所有require-dev下的包 - 升级后必须强制重建自动加载：
composer dump-autoload -o，否则新增类可能找不到 - 务必在升级步骤后加验证：运行
composer show guzzlehttp/guzzle确认版本号，并用composer why-not php:8.3快速排查潜在平台冲突
多人协作时 lock 文件不一致的典型报错怎么解
CI 报 Your lock file does not contain a compatible set of packages，本质是 composer.json 和 composer.lock 脱节。这不是网络或权限问题，而是协作断点：
- 最稳妥解法：让修改了
composer.json的人先提交新composer.lock，其他人git pull后再composer install - 临时同步可用
composer update --lock，它只重写 lock 文件元数据（如 PHP 版本声明），不重装包、不改依赖树 - 绝对不要在 CI 脚本里加
--ignore-platform-reqs绕过——它掩盖的是约束缺失，不是环境问题 - 团队应统一启用
"prefer-stable": true，避免因预发布版本（如v3.0.0-beta1）导致本地能装、CI 拒绝安装
共享依赖的“更新”从来不是 CI 的职责，而是开发流程中一个受控、可追溯、带验证的提交动作。把 composer.lock 当成代码一样 Code Review，比任何自动化升级都管用。
