不能手动编辑composer.lock，因其是依赖图的哈希快照而非配置文件；改错任意字段（如version、hash、platform）会导致校验失败、子依赖不一致、类加载错误或ci环境不可重现。
直接删掉 composer.lock 和 vendor，再跑 composer update，是最稳妥的同步方式；手动合并 lock 文件或只删某几行，几乎必然导致依赖不一致或安装失败。
为什么不能手动编辑 composer.lock？
composer.lock 不是配置文件，而是 Composer 解析依赖后生成的“快照”——它包含每个包的 exact version、install path、sha256 hash、require 链和 platform 条件。手动改其中一行（比如把 monolog/monolog 的版本号从 3.2.1 改成 3.5.0），会导致：
- hash 校验失败，
composer install直接中止 - 子依赖版本未同步更新，
composer show --tree monolog/monolog会显示冲突路径 - PHP 平台约束（如
"php": "^8.2"）可能被旧版包绕过，新环境运行时报Class not found
团队协作中 composer.lock 冲突了，怎么合并？
Git 报 conflict 时，别打开 lock 文件逐行对比。正确做法是：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先
git checkout --ours composer.json或--theirs，选一个作为基础，再手动合并双方新增的require和require-dev行 - 删掉本地
composer.lock和整个vendor/目录 - 运行
composer update --lock（不是install），让当前 Composer 版本重新解析并生成新 lock - 检查
git diff composer.lock：确认只有预期变更，没有意外的全量重排或降级
CI/CD 流水线里依赖总不一致？检查这三点
常见问题不是 lock 文件本身错，而是执行环境与 lock 文件记录的平台不匹配：
-
composer install失败报Root composer.json requires php ^8.2, but your PHP version (7.4.33) does not satisfy that requirement→ 检查 CI runner 的 PHP 版本是否和 lock 文件顶部"platform": {"php": "8.2.10"}一致 - 报
file could not be downloaded: failed to open stream→ Windows 下常因 OpenSSL ca-bundle 路径失效，临时加--no-secure-http（仅限调试），生产环境应修复openssl.cafile配置 - 流水线用
composer update而非composer install→ 这会让每次构建拉取不同版本，彻底破坏可重现性；必须强制使用install
升级 PHP 版本后 composer.lock 不生效？缓存和元数据要清干净
PHP 从 8.1 升到 8.3 后，composer update 仍装旧包，往往不是命令没跑，而是 Composer 复用了旧环境下的解析结果：
- 删掉
~/.composer/cache/repo/https---packagist.org/（Linux/macOS）或%APPDATA%\Composer\Cache\Repo\https---packagist.org\（Windows） - 删掉项目下
vendor/composer/installed.json和composer.lock - 运行
composer update --dry-run -v，确认日志里出现Downloading https://packagist.org/packages.json - 若还卡在旧版，加
--ignore-platform-reqs临时跳过检查，但最终必须移除该参数并验证扩展是否齐全（如ext-intl,ext-mbstring）
最易被忽略的一点：lock 文件只保证“当时能跑”，不承诺长期可用。Packagist 上的包可能被删、tag 被 force-push、镜像源同步延迟——所以定期 composer outdated + 小步更新，比攒半年一次大更新更安全。
