composer install装旧包或新包取决于composer.lock：存在则严格按其安装；不存在则退化为update，解析最新兼容版并生成新lock。
必须用 composer install，不能用 composer update —— 否则线上依赖就失控了。
为什么 composer install 会装旧包或新包？
它完全不看 composer.json 里的 ^ 或 ~，只认 composer.lock 里写的版本号。有这个文件，就照着装；没有，就退化成 composer update，重新算一遍最新兼容版本。
- 常见错误：新人 clone 项目后手删
composer.lock，再composer install→ 装了一堆没测过的新小版本，本地直接报Class not found - 更隐蔽的问题：
composer.json改了依赖但没人跑composer update提交新lock→ 别人install还是旧版，功能缺失却不报错 -
composer.lock的content-hash字段基于composer.json的require、repositories、minimum-stability生成，改了这些但没更新lock，会导致解析行为不一致
生产环境部署必须加的三个参数
默认的 composer install 是为开发设计的，线上直接跑等于埋雷。
-
--no-dev：跳过require-dev里的包（如phpunit、phpstan），否则可能把测试工具打进生产镜像 -
--optimize-autoloader（或简写-o）：生成 classmap，避免运行时遍历目录找类，性能提升明显；Laravel 9+ 建议换用--classmap-authoritative替代已废弃的--optimize -
--no-interaction（或简写-n）：防止 CI/CD 流水线卡在交互提示上，比如问你是否信任某个仓库
正确命令：composer install --no-dev --optimize-autoloader --no-interaction
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer.lock 被删或没提交会怎样？
不是“重装一遍而已”，是彻底放弃控制权：Composer 会从头计算满足约束的最新组合，可能引入未经验证的补丁、降级的子依赖，甚至带漏洞的老版本（因新版本要求更高 PHP 版本而被跳过）。
- 典型后果：
monolog/monolog从2.10.2升到3.0.0，日志 handler 接口全变；guzzlehttp/guzzle因依赖链变化降级到7.2.0，触发已修复的 DNS 缓存 bug - CI 构建失败但本地能跑？先检查 Git 是否漏提交
composer.lock—— 没它，composer install就是裸update - 合并 PR 时
composer.lock出现冲突，别手动编辑，应删掉冲突文件，再composer install重建（前提是composer.json已合入）
Docker 构建时 composer.lock 怎么用才不慢？
慢的根本原因不是网络，是 Docker 分层缓存失效：只要 composer.lock 变了，整个 vendor/ 就得重装。
- 必须把
composer.json和composer.lock单独 COPY 进镜像，再执行composer install—— 这样 Docker 才能复用前一次的依赖层 - 国内环境务必配阿里云镜像：
RUN composer config -g repo.packagist https://mirrors.aliyun.com/composer/ - 避免
git clone后再composer install，这会让所有依赖安装步骤无法被缓存 - 构建前确认
composer.lock顶部的platform字段与 Dockerfile 中的 PHP 版本一致，否则会报Your platform does not meet the requirements
真正容易被忽略的是：Docker 构建时若用了多阶段，vendor/ 复制过去后，还得单独跑 composer dump-autoload --no-dev --classmap-authoritative，否则 autoload 仍含 dev 路径，线上可能加载不到命令类。
