先用git checkout --ours composer.lock或--theirs恢复干净版本，再删vendor后运行composer install；若lock已损坏且无干净备份，则删vendor和lock，执行composer update --no-install生成新lock，再composer install。
composer.lock JSON decode error 直接报错怎么救
这不是语法错误，而是文件内容与 Composer 期望的结构不匹配——常见于手动编辑、Git 合并冲突残留、换行符损坏或 UTF-8 BOM 头污染。报错如 JSON decode error: Syntax error 或 Unexpected token ... 时，别急着重写 JSON，先确认是否被破坏。
快速验证方式：php -r "json_decode(file_get_contents('composer.lock'), true) === null && die('invalid'); echo 'ok';"。输出 invalid 即确认解析失败。
- 检查是否有 Git 合并标记：用
grep -n '>>>>>>' composer.lock，有结果说明没解决完冲突，必须先用git checkout --ours composer.lock或--theirs恢复干净版本 - 检查 BOM：运行
head -c 3 composer.lock | xxd，若输出含ef bb bf，说明带 UTF-8 BOM，用sed -i '1s/^\xEF\xBB\xBF//' composer.lock（Linux/macOS）或 Notepad++ 转为 UTF-8 无 BOM 保存 - 检查换行符：Windows 编辑器可能插入
\r\n导致某些 PHP 版本解析异常，用dos2unix composer.lock统一为\n
删了 vendor 但 composer.lock 损坏，还能 install 吗
不能。Composer 在 install 前会完整校验 composer.lock 的 JSON 结构 + 字段合法性（比如 packages 必须是数组、每个包必须含 name 和 version），任一缺失或类型错都会中断，不会 fallback 到 composer.json。
此时唯一安全路径是重建 lock 文件：
- 先确保
composer.json是干净的（composer validate返回 valid） - 删掉
vendor/和损坏的composer.lock - 运行
composer update --no-install：它只生成新composer.lock，不碰vendor/，避免中间出错 - 再跑
composer install完成安装
注意：不要用 composer install --ignore-platform-reqs 强行跳过 JSON 校验——它不绕过解析阶段，只是跳过 PHP 扩展等运行时检查。
为什么改了 composer.json 但没 run update，install 就报 content-hash 不匹配
content-hash 是对 composer.json 文件全文（含空格、换行、键顺序）做的 SHA-256，不是校验和，而是“快照指纹”。只要文件字节变了，hash 就变；而 composer install 会比对它和当前 composer.lock 里记录的值——不一致就警告，但默认仍继续安装。
真正会中断的是以下两种情况：
- 你启用了
lock校验（如 CI 中设COMPOSER_DISCARD_CHANGES=1），此时不一致直接报错退出 -
composer.json里删了某个包，但composer.lock还留着它的条目，install会提示Required package "xxx" is not present in the lock file并拒绝执行
所以修改 composer.json 后，要么 composer update 重算整个依赖树，要么至少 composer update --lock 只更新 lock 文件（不装不卸），否则 install 行为不可控。
CI 流水线里 composer.lock 被忽略或未提交，install 会怎样
如果 .gitignore 里误加了 composer.lock，或 CI 构建节点拉不到它，composer install 会立刻失败，报 No composer.lock file present（v2.5+）或静默 fallback 到 update 行为（旧版），后者极危险。
后果很具体：
- 不同构建时间、不同机器上，
guzzlehttp/guzzle可能装出7.8.1或7.9.0，哪怕composer.json写的是^7.8 - 某次 build 因小版本变更引入 BC break，线上报
Call to undefined method却无法复现 - 安全扫描工具（如 OpenSCA）因缺失
composer.lock只能退化到粗粒度分析，漏掉已知 CVE
务必确保 composer.lock 提交进 Git，且 CI 配置中显式检查其存在：test -f composer.lock || (echo "LOCK FILE MISSING" >&2; exit 1)。
