composer install 是按 composer.lock 精确还原依赖的确定性操作，不更新包、不求解依赖、不修改 lock 文件；版本不变因 lock 未变，改 json 后需用 require 或 update 才生效。
composer install 本来就不该更新包
它不是“装新包”的命令，而是按 composer.lock 精确还原依赖快照的确定性操作。只要 composer.lock 存在且内容完整，composer install 就只做一件事：把 lock 文件里写死的每个包、每个 commit hash、每个 dist shasum，原样下载并解压到 vendor/。它不查远程有没有新版本，也不跑依赖求解器，更不会改 lock 文件。
为什么删了 vendor 后 run install 还是旧版本？
因为 composer.lock 没变。只要 lock 文件还在，哪怕你手动删光 vendor/，composer install 依然会拉取 lock 里指定的旧版本——哪怕镜像站上早已发布 v3.6.0，它也只认 lock 里的 v3.5.0。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 验证方式：执行
composer install -v，看终端输出的 downloading 行，URL 后面的 hash 是否和composer.lock里对应包的"dist": {"shasum": "..."}一致 - 常见误操作：刚 clone 项目就跑
composer install，结果失败，其实是composer.lock根本没提交进 Git，导致 fallback 到update行为（但没人告诉你） - 真正触发版本变更的，永远是
composer update—— 它读composer.json的约束，调用 SAT 求解器，生成新 lock
执行 composer install 却报 “Package is not installed”
这不是网络或权限问题，而是 composer.lock 和 composer.json 不一致，或者环境不满足 lock 中某包的平台要求。
- 先运行
composer check-platform-reqs，看是否缺ext-mbstring或 PHP 版本太低（比如 lock 里锁了要求 PHP >=8.1 的包，而你本地是 8.0） - 检查
composer.json的"config": {"platform": {...}}是否硬编码了和实际不符的 PHP 版本 -
composer install报错时带ignore-platform-reqs提示，那是绕过检查的临时开关，不是解决方案；加了它装出来的包大概率运行时报错
想装某个新包，却误用了 install
直接改 composer.json 然后跑 composer install 是无效的。Composer 不会扫描 composer.json 新增的 require 条目，除非 lock 文件不存在或内容不匹配。
- 正确做法：用
composer require vendor/package—— 它会自动写入composer.json、更新composer.lock、下载包、刷新 autoload 映射 - 如果已经手动改了
composer.json，必须跑composer update vendor/package（而非 install）才能生效 - 漏掉 autoload 更新是 Laravel 里 “Class not found” 最常见原因：文件在 vendor 里，但
vendor/autoload.php没重生成，PSR-4 映射就找不到类
composer install 的行为完全由 composer.lock 驱动，而这个文件本身是 composer update 的输出结果。很多人卡在“为什么我改了 json 却没效果”，本质是混淆了声明（json）、快照（lock）、执行（install）三层逻辑。 
