Composer.lock 频繁 Git 冲突源于其文本结构敏感性：每次 install/update 全量重写 JSON（键序、缩进、空行、platform、content-hash 均变化），Git 行级比对必然冲突；解法是协作前统一执行 composer update --lock，禁用手动编辑或 --no-lock，确保环境一致与契约可信。
Composer.lock 文件为什么总在 Git 合并时冲突
因为 composer.lock 是二进制安全但文本结构敏感的快照文件，每次 composer install 或 composer update 都会重写整个文件（包括哈希、依赖树顺序、平台信息），哪怕只改了一个包版本，生成的 JSON 键顺序、缩进、空行都可能不同。Git 按行比对，自然高频冲突。
- 不是“谁改得多”，而是“谁最后跑了一次
composer install”——它会覆盖所有已有字段 - 团队里有人用 PHP 8.2、有人用 8.1，
composer.lock里platform-check和content-hash也会不同 -
composer update foo/bar和composer update生成的 lock 文件结构差异极大，混着提交极易冲突
合并前必须统一执行 composer update --lock
这不是可选项，是协作前提。只要多人修改了 composer.json（比如增删包、改版本约束），就必须先让所有人基于同一份 composer.json 生成一致的 composer.lock，再提交。
- 发起方先
git pull origin main拉最新composer.json - 运行
composer update --lock（不带包名）——它只更新 lock 文件结构，不改任何包版本 - 检查
git status：如果只有composer.lock变动，说明环境一致；如果有其他变动，说明本地composer.json还没同步干净 - 提交这个新 lock 文件，再发起 PR / 合并
遇到冲突时别手动编辑 composer.lock
手动修 JSON 字段顺序、删空行、调缩进，大概率破坏 content-hash 校验，后续 composer install 会报错：Invalid argument supplied for foreach() 或直接拒绝安装。
从 Git 仓库历史中彻底删除文件
下载
|Git删除了文件，但还会在Git 仓库历史中遗留。 - 想要从 Git 历史移除敏感信息（密码、密钥、token、私钥） - 想要删除意外提交的大文件 - 想要重写 Git 历史、移除特定文件的所有痕迹 - 提到 "force push"、"重写 commit 历史" - 需要从所有分支、所有 tag 中删除某个文件
- 放弃当前 merge：
git merge --abort - 确保
composer.json已是目标分支最新版（git checkout origin/main -- composer.json） - 运行
composer update --lock重新生成 lock - 此时
git add composer.lock && git commit就是干净解法 - 若必须保留某分支的特定包版本（如临时降级
monolog/monolog），应先composer require monolog/monolog:^2.0再--lock，而非手改 lock
CI/CD 和部署环节要禁用 composer install --no-lock
很多团队为“绕过 lock 冲突”在 CI 脚本里加 --no-lock，结果上线环境实际装的包和开发机不一致，半夜出问题根本没法复现。
-
composer install必须默认读composer.lock，这是 Composer 设计原意 - CI 流水线第一步就该校验：
composer validate --strict，失败则立刻阻断构建 - 部署机如果提示
Package x is not installed，八成是漏传了composer.lock，而不是该删 flag
真正麻烦的从来不是怎么解一次冲突，而是团队没对齐“谁有权限改 composer.json”“什么场景必须 update --lock”。lock 文件不是普通配置，它本质是一份不可信环境下的确定性契约——签之前，所有人得看同一份草稿。
