只有 composer update 会重写 composer.lock，composer install 默认只读取它且不修改 vendor/；备份依赖的正确方式是直接复制 composer.lock 文件，而非依赖 composer.json。
composer install 和 composer update 哪个会改 lock 文件
只有 composer update 会重写 composer.lock，composer install 默认只读取它。如果你只是想备份当前依赖状态，composer install 不动 lock 文件，也完全不碰 vendor/ —— 它只校验一致性，不更新任何东西。
常见错误现象：composer install 报错 “Your lock file does not contain a compatible set of packages”，说明本地 composer.lock 和 composer.json 已不匹配，这时候强行用 --ignore-platform-reqs 或删 lock 再装，等于绕过备份意图。
- 导出依赖快照的正确起点，永远是干净的
composer.lock（即和composer.json一致） - CI/CD 中应固定用
composer install --no-dev，而不是update，否则每次构建都可能引入新版本 -
composer update --dry-run可预览哪些包会被升级，避免误触 lock 文件
怎么导出可复用的扩展包列表（不含版本号）
用 composer show --name-only 最直接。它只输出包名，一行一个，没有版本、描述或空行，适合存为 packages.txt 供人工核对或脚本消费。
使用场景：审计第三方组件、迁移项目时比对依赖差异、向安全团队提交清单。
-
composer show --name-only --no-dev排除开发依赖，更贴近生产环境真实依赖 - 别用
composer show全量输出——含版本号和描述，人眼难扫，脚本难解析 - 如果要带版本号导出（比如给同事看当前用了啥），用
composer show --direct，它只列根依赖（非 transitive），且格式稳定
怎么生成带版本号的锁定文件副本（真正可还原的备份）
最可靠的方式就是直接复制 composer.lock 文件，改名为 composer.lock.backup 或按日期命名（如 composer.lock.20240520）。Composer 本身不提供“导出 lock”命令，因为 lock 文件本身就是标准备份载体。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
容易踩的坑：composer dump-autoload 不影响 lock；composer require xxx 会自动触发 update 并改 lock——这不是备份，是修改。
- 备份前先确认
git status里composer.lock是 clean 的，没被意外修改过 - 不要用
composer install --dry-run想“模拟导出”，它根本不输出任何依赖信息 - 若项目用了
platform-check或自定义config.platform，备份时得一并记下这些配置，否则还原时 PHP 版本兼容性可能出问题
为什么不能靠 composer.json 当依赖备份
composer.json 只声明“想要什么”，不记录“实际装了什么”。比如你写 "monolog/monolog": "^2.0"，lock 文件才确定是 2.10.2 还是 2.9.1。线上故障常源于小版本差异，只备份 json 等于没备份。
性能影响：还原时若只有 json 没 lock，composer install 会退化为 update 行为，重新解析整棵树、查 packagist、下载最新匹配版本——慢且不可控。
- 私有包或已归档的旧版本，在 packagist 下线后，仅靠 json 根本无法还原
- 某些包在不同 Composer 版本下解析结果不同（如 v1 vs v2 对 caret range 的处理），lock 文件才是唯一真相
- 团队协作中，有人 commit 了 json 却忘了 commit lock，下次
install就悄悄变了依赖
真正关键的不是“导出动作”，而是确保 composer.lock 始终被纳入版本控制、每次变更都经过审查——它不是中间产物，是契约本身。
