必须提交 composer.lock 到 git，它是依赖快照的唯一权威记录；不提交会导致 composer install 退化为重新解析，引发各环境依赖不一致、ci失败、线上白屏等问题。
composer.lock 必须提交到 Git，否则所有“锁定”都是假的——它不是缓存，是依赖快照的唯一权威记录。
composer.lock 为什么必须进 Git
不提交 composer.lock，composer install 就退化成按 composer.json 重新解析依赖，哪怕你写了 "monolog/monolog": "2.9.1"，只要 lock 缺失，CI 或新同事装出来的就可能是 2.9.2（镜像源缓存了新版本、PHP 版本微差、平台扩展状态不同都会触发重解）。
-
.gitignore里误写composer.lock或*lock*是最常见误操作 - 新项目初始化后，第一次
composer install完就得立刻git add composer.lock - 多人协作时，如果 A 提交了 lock，B 改了
composer.json却直接composer install，会报错Your requirements could not be resolved to an installable set of packages——这时 B 应该运行composer update并提交新 lock，而不是删 lock 再装
怎么验证 lock 文件是否真正生效
生效靠的是 composer install 命令本身，不是 lock 文件存在就行。它必须被读取并严格执行。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 删掉
vendor/和composer.lock，只留composer.json，再跑composer install：如果没报错且装出的包版本和之前不一致，说明 lock 没起作用（大概率是被 .gitignore 过了或 CI 脚本用了update） - CI/CD 脚本里必须用
composer install --no-dev --no-interaction，绝不能用composer update - 上线前可加一道保险：
composer install --locked，它会校验composer.lock中每个版本是否仍满足composer.json的约束，不满足直接报错退出
不同 PHP 版本导致 lock 失效怎么办
composer.lock 默认包含平台配置（如 php、ext-zip），如果团队有人用 PHP 8.1，有人用 8.2，而某包在两个环境下解析出的依赖路径不同，lock 就可能失效。
- 检查 lock 文件顶部的
platform字段，建议显式声明团队统一的最小 PHP 版本，例如："config": {"platform": {"php": "8.1.0"}} - 避免在
composer.json中写过于宽松的 PHP 约束，比如"^7.4 || ^8.0"，这会让 Composer 在不同环境下选不同分支，lock 失去意义 - Windows 和 Linux 下某些扩展（如
ext-sockets）默认状态不同，若项目依赖这类扩展，应在config.platform中统一模拟，否则 lock 在 CI（Linux）上通过，本地（Win）却装不上
手动改 lock 文件行不行
不行。它不是配置文件，而是快照——记录每个包的确切版本、哈希值、完整依赖路径。手动改极易出错。
- 比如改了某个包的
version但没同步更新dist/sha256，下次composer install会校验失败并报错Invalid checksum for ... - 真正该操作的是
composer.json，再让 Composer 重新生成 lock：要锁定某包，就写死版本号，例如"monolog/monolog": "2.9.1"；要锁住整棵树，就运行composer update --lock（仅重写 lock，不碰 vendor） - 想回退？直接
git checkout composer.lock && composer install就行
最难的不是命令怎么敲，而是所有人得明白：composer.lock 不是“生成物”，它是和 composer.json 平级的源码——删它、忽略它、绕过它，等于主动放弃版本控制。
