composer.lock由Composer自动生成，执行composer install（无锁文件时）或composer update（有锁文件时）触发，必须提交至Git以确保环境一致。
composer.lock 文件不是手动创建的，而是由 Composer 在执行特定命令时自动生成的。它本质是依赖解析结果的快照，关键在于“触发时机”和“是否被提交”。
执行 composer install 时自动生成锁文件
只要项目目录下没有 composer.lock，首次运行 composer install 就会：
- 解析 composer.json 中的 require 和版本约束（如 "guzzlehttp/guzzle": "^7.2"）
- 计算出满足所有依赖关系的**最新兼容版本组合**
- 下载包到 vendor/ 目录
- 同时生成并写入 composer.lock，记录每个包的确切版本、哈希值、嵌套依赖树
执行 composer update 时更新锁文件
当已有 composer.lock 时，运行 composer update 会：
- 忽略当前 lock 文件内容，重新基于 composer.json 解析整个依赖树
- 升级到符合约束的**最新可用版本**（可能跨 patch/minor/major）
- 覆盖原有 composer.lock，写入新版本组合
常见误操作：
- 在 CI/CD 流水线里用 composer update 替代 composer install → 每次构建都拉新版本，锁文件形同虚设
- 本地删了 composer.lock 后直接 composer install → 等效于全量重解析，版本不可控
必须把 composer.lock 提交到 Git
这是锁定生效的前提，否则：
- 新成员克隆仓库后运行 composer install，因无 lock 文件，实际走的是 update 逻辑
- CI 构建时若 .gitignore 里写了 composer.lock，会导致环境不一致
- 生产部署时若 lock 文件缺失，composer install 无法还原历史版本
正确做法：
- git add composer.lock
- git commit -m "chore: lock dependencies"
- 确保团队所有机器都从同一份 lock 文件安装
composer install --no-dev 不影响锁文件生成
--no-dev 只控制是否安装 require-dev 中的包，不影响 lock 文件本身：
- 锁文件始终包含全部依赖（含 dev），无论安装时是否启用 --no-dev
- 生产环境应固定使用 composer install --no-dev --no-interaction --no-progress，避免交互和冗余输出
- 不要试图用 composer dump-autoload 或其他命令“生成锁文件”，它只负责自动加载优化
真正起作用的从来不是“怎么生成”，而是“谁在什么时候生成、是否被共享”。锁文件一旦被删或未提交，就等于撤掉了所有版本契约的基石。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
