composer install 无法恢复丢失的 composer.lock，因其仅按 lock 还原依赖；必须用 composer update 重建，但会重新解析版本，存在 BC 风险。
不能靠 composer install 恢复丢失的 composer.lock，必须用 composer update 重建——但重建不是“恢复”，而是重新抽签，风险需主动评估。
为什么 composer install 无法生成 composer.lock
新版 Composer（v2.5+）直接报错 Command "install" is not defined；旧版可能静默失败，但 vendor/ 内容一定不对。因为 install 的语义是“按 lock 还原”，没 lock 就没依据，它不负责推导依赖树。
常见误操作：
- 直接删掉 composer.lock 后跑 composer install
- 在 CI 脚本里漏传 composer.lock，指望 install 自动补上
- 以为 composer install --no-cache 能触发重建——它只是跳过缓存，仍需要 lock 存在
composer update 和 composer update --lock 的关键区别
两者都写新 lock，但行为完全不同：
-
composer update：重新解析composer.json所有约束，查最新匹配版本，升级包、改vendor/、重写lock——可能引入 BC break，慎用于生产环境 -
composer update --lock（v2.2+）：只重写lock文件，vendor/完全不动，lock 内容对齐当前已安装状态——适合 git 拉取时 lock 被覆盖、或手动编辑出错后的修复
注意：--lock 不校验平台兼容性（如 PHP 版本），也不检查 require 是否满足，它只是“快照同步”。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
重建前必须确认的三件事
盲目 update 可能导致线上环境不一致，尤其在 CI/CD 中：
- 检查
composer.json中"config": {"platform": {"php": "8.1.0"}}是否与目标环境一致，否则update可能选错版本 - 确认是否启用了
composer config lock.exclude-dev true——这会让 dev 依赖不进 lock，但install时仍会装（除非加--no-dev） - CI 中若用
composer install --no-interaction --prefer-dist，要确保所有机器用同一 Composer 版本（v2.2+ 和 v1.x 生成的 lock 格式互不兼容）
最稳妥的重建流程（上线前验证推荐）
分步控制变量，而非“删 lock → 盲跑”：
- 先运行
composer update --dry-run，看哪些包会被升级、PHP 扩展是否满足、有无冲突提示 - 确认无风险后，执行
composer update --with-all-dependencies（避免部分依赖卡死版本，导致间接依赖未更新） - 如果只想更新 lock 文件本身（
vendor/不动），用composer update --lock --no-install
真正容易被忽略的是：lock 文件的“时效性”只保证“当时能跑”，不保证“永远可用”。它记录的是某次解析结果，一旦源包被删、镜像失效、平台要求变更，这个 lock 就可能再也装不上。
