composer.lock不可手动编辑，因其是依赖图的哈希快照，含包名、版本、dist.sha256、require闭包及PHP扩展要求；Git合并标记会破坏JSON结构，导致校验失败与运行时错误。
为什么不能手动编辑 composer.lock
它不是配置文件，而是依赖图的哈希快照——包含每个包的 name、version、dist.sha256、require 闭包、甚至 PHP 扩展要求。Git 行级合并标记（<<<< HEAD）会直接破坏 JSON 结构；哪怕侥幸解析通过，dist.sha256 校验失败会导致类加载中断、扩展缺失报错，且问题常延迟到运行时才暴露。
如何用 Git 钩子阻止提交损坏的 composer.lock
在 .git/hooks/pre-commit 中加入校验逻辑，比靠人盯更可靠：
- 运行
composer validate --no-check-publish，检查 lock 文件语法与完整性 - 执行
composer install --dry-run，确认composer.json和composer.lock能匹配（不下载、不写 vendor） - 用
jq检查关键字段是否存在：jq -e '.packages, .packages-dev, .content-hash' composer.lock > /dev/null - 任意一项失败就
exit 1，中断提交
注意：该钩子需团队统一安装，建议通过脚本分发（如 make setup-hooks），而非仅靠文档提醒。
composer.lock 冲突时唯一安全的重建方式
发生冲突后，手动删标记、凑版本号、选一方保留——全都不行。必须走机器可验证的重建流程：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先完成
composer.json的 clean merge（无冲突、语义正确） - 删除本地
vendor/和composer.lock - 运行
composer update --no-install（只重算 lock，不装包） - 再跑一次
composer install --dry-run确认无差异 - 最后
git add composer.lock提交
这个流程绕过了所有人工判断，把“是否一致”交给 Composer 自身校验，而不是开发者 eyeball diff。
CI 中强制拦截非合规 lock 提交
光靠本地钩子不够，CI 是最后一道防线：
- 在 GitHub Actions 或 GitLab CI 中加一步：
composer install --no-dev --dry-run - 如果命令失败（比如 lock 缺包、hash 不匹配、require-dev 字段丢失），直接 fail job
- 同时检查
git status --porcelain | grep composer.lock，若 lock 文件被修改但composer.json未变，也视为异常（说明有人删 lock 后 run install）
这类检查会让“误删 lock 后 install”或“跳过 update 直接 commit 新 lock”的行为在 PR 阶段就被卡住，不给上线留隐患。
真正难的不是技术手段，而是让所有人接受：lock 文件的变更必须伴随可追溯的 composer.json 修改，且只能由 composer update 生成——它不是给人改的，是给机器验的。
