composer install 是部署和协作的唯一安全选择，严格按 composer.lock 安装精确版本；composer update 会重算依赖并覆盖 lock 文件，存在兼容性风险，CI/CD 中禁用。
composer install 严格按 composer.lock 安装精确版本，是部署和协作的唯一安全选择；composer update 忽略 composer.lock，重新解析 <code>composer.json 并升级依赖，属于有风险的主动变更操作——不是“更新”，而是“重算+覆盖”。
为什么 composer install 报错 “Your lock file does not contain a compatible set of packages”
这是 composer.json 和 composer.lock 明显不一致的信号，不是网络或权限问题。
- 常见原因：别人改了
composer.json（比如增删包、调整版本约束），但没提交新的composer.lock；或者你本地手动删过composer.lock - 错误做法：直接跑
composer update强行同步——这会悄悄升级一堆包，可能引入兼容性问题 - 推荐做法：
- 先
git pull拉取最新代码（含队友提交的composer.lock），再运行composer install - 若确认要同步
composer.json的改动，用composer update --lock——它只重写lock文件，不重装包，更可控 - 想预览变更？加
--dry-run：composer update --dry-run
- 先
composer update monolog/monolog 真的只更新这一个包吗
不。它会重跑整个依赖求解器，连带更新所有子依赖（包括间接依赖），结果不可预测。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer update monolog/monolog不是“改一行版本号”，而是丢弃当前composer.lock中关于 monolog 及其全部依赖的记录，从头计算满足composer.json中所有约束的新组合 - 哪怕
monolog/monolog版本只升了一个 patch（如2.10.0 → 2.10.1），其子依赖psr/log可能从1.1.4升到2.0.0，而后者是破坏性大版本 - 想最小化影响？加
--with-dependencies显式控制范围，或优先用composer require monolog/monolog:^2.10（它会走受控 update 流程并写入 lock） - CI/CD 脚本里绝对不要出现
composer update——没有人工审查环节，等于放任环境漂移
为什么 CI 或生产环境必须用 composer install
因为它的行为是确定性的：无计算、无决策、无网络探测，只有 I/O。
-
composer install读composer.lock→ 拿到每个包的精确版本 + hash → 从本地缓存复制或从镜像下载对应 zip → 解压到vendor - 全程不访问 packagist.org API，不调用依赖求解器（Solver），CPU 几乎不参与，耗时稳定在秒级
-
composer update则必须遍历所有可用版本、检查 PHP 版本/扩展/其他包约束、回溯冲突路径——这是 NP-hard 问题，耗时可能从几秒飙升到数分钟，且每次结果未必相同 - 漏掉
--no-dev是高频失误：生产环境执行composer install时默认装 dev 包（如phpunit），增大攻击面和部署体积；应始终加--no-dev
最易被忽略的一点：当项目根目录下没有 composer.lock 时，composer install 会退化为 composer update 行为——但它不会生成 lock 文件，导致后续 install 依然不稳定。所以新项目初始化后第一件事，不是写代码，是确认 composer.lock 已存在并已提交到 Git。
