composer.lock由composer install或update自动生成，是记录包精确版本与哈希的快照；手动修改易致校验失败，应通过修改composer.json后运行相应命令更新。
composer.lock 是谁生成的、能不能手动改
它由 composer install 或 composer update 自动生成，不是配置文件，而是「快照」——记录当前所有包的确切版本、哈希值、依赖树结构。手动改 composer.lock 极易出错：比如改了某个包的 version 但没同步更新 dist/sha256，下次 composer install 会校验失败并报错 Invalid checksum for ...。
真正该操作的是 composer.json，再让 Composer 重新生成 lock 文件：
- 要锁定某包到固定版本？在
composer.json中写死版本号，例如"monolog/monolog": "2.9.1"（不带^或~） - 要锁住整个依赖树？运行
composer update --lock（仅重写 lock，不碰 vendor） - 想回退到上一次的 lock 状态？直接
git checkout composer.lock && composer install
为什么 composer update 有时不更新 lock，有时又全重写
关键看有没有指定包名，以及 composer.json 是否变动：
- 执行
composer update（无参数）：读取composer.json所有约束，重新解析整棵树，生成全新composer.lock - 执行
composer update monolog/monolog：只更新该包及其子依赖，其他包版本保持不变（只要兼容） - 如果
composer.json没变，但你删了composer.lock，再跑composer install—— 它会报错Composer could not find a composer.json file（别信，其实是 lock 缺失导致无法确定安装源）
常见陷阱：CI 环境里误用 composer update 而非 composer install，导致每次构建都产生新 lock，破坏可重现性。
composer install 报 “lock file is not up to date” 怎么办
这个警告不是错误，但意味着 composer.json 和 composer.lock 不一致 —— 通常是有人改了 json 但忘了 update，或者 git merge 冲突后手动修了 json 却漏掉 lock。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 安全做法：先确认改动是否预期，再运行
composer update --dry-run看会动哪些包 - 如果只是加了个
require-dev工具，且不希望影响线上依赖，可用composer update --lock快速同步 lock - 如果 CI 报这个警告又被设为 fail-on-warning，别硬压 warning，应该修复根源：确保每次改
composer.json后都提交对应的composer.lock
注意：composer install --no-interaction --no-progress 不会跳过该检查，它只跳过交互和进度条。
lock 文件里 content-hash 和 packages 的实际作用
content-hash 是 composer.json 内容的 SHA256，不是 lock 文件自身的哈希。Composer 用它快速判断「json 有没有被悄悄改过」—— 如果 hash 对不上，就拒绝用 lock 安装，强制要求 update 或报错。
packages 数组才是真正的依赖快照，每项含：
-
name、version（如"2.9.1"，注意不是"2.9.*"） -
dist下的url和sha256：决定下载源和校验方式 -
source下的reference：Git commit hash，用于dev-版本
这意味着：哪怕你本地 composer.json 写 "^2.9"，只要 lock 里存的是 2.9.1，install 就永远装这个精确版本 —— 这才是“锁定”的本质。别指望靠改 lock 里的 version 字段来降级，得走 composer require "pkg:1.2.3" 或改 json 后 update。
