必须用 verify-checksums + validate + dry-run 三重校验保障 composer.lock 一致性：verify-checksums 校验文件哈希防篡改，validate --strict 检查 JSON 语义合法性，install --dry-run 验证 lock 与 json 兼容性及平台约束。
composer.lock 一致性不能靠“看起来一样”来判断，必须用 verify-checksums + validate + dry-run 三重校验，否则 CI 构建或部署时大概率出问题。
verify-checksums 是唯一能发现 vendor 文件被篡改的命令
它不看文件名、时间戳或目录结构，而是逐个读取 vendor/{vendor}/{package} 下所有源文件（跳过 .git、tests/、vendor/composer/），合并字节流后计算 SHA256，再和 composer.lock 中对应包的 dist.sha256 字段比对。不匹配就报错。
常见失效场景：
- 没启用
COMPOSER_EXPERIMENTAL=1—— 命令直接静默跳过所有校验 - 用了
--prefer-source安装 —— 这类包没dist.sha256，自动被跳过 - 手动改过
vendor/里的某行代码 ——diff vendor/看不出来，但verify-checksums --strict会立刻失败 - 不加
--strict—— 哈希不一致只警告，返回码仍是 0，CI 无法感知
validate --strict 必须在 CI 中强制执行
composer validate 默认只检查 JSON 语法，对语义错误（比如拼错的 "autoloader"、废弃的 "minimum-stability": "dev-master"）全当警告放过，且 exit code 为 0。这在自动化流程里等于没校验。
CI 中应固定使用：
-
composer validate --strict --no-check-publish——--no-check-publish避免因网络问题中断流水线 - 必须确保
composer.json是 UTF-8 编码、无 BOM、无注释（JSON 不支持//或/* */） - 若报错
line 12 at column 5，优先用php -r "json_decode(file_get_contents('composer.json'));"定位真实语法位置
install --dry-run 是验证 lock/json 逻辑一致性的最后防线
它不真正写入 vendor/，但会完整模拟 composer install 的依赖解析过程：加载 composer.lock → 校验其与 composer.json 是否兼容 → 检查平台约束（如 config.platform.php）是否满足 → 报出冲突或缺失项。
典型失败原因：
-
composer.json被修改过，但composer.lock没更新（比如同事忘了git add composer.lock） -
config.platform.php写成"8.1"而非"8.1.10"—— 小版本不写死，平台约束会被忽略 - 本地 PHP 版本是 8.2，但
config.platform.php锁的是 8.1.10，而某个新包要求 8.2+ →--dry-run会明确提示不兼容
真正难搞的不是命令怎么写，而是很多人把 composer.lock 当成“生成完就扔那儿”的快照——它其实是个活的契约，每次 git pull 后都该跑一遍 composer install --dry-run，每次 PR 提交前都该让 CI 执行三重校验。漏掉任意一环，环境漂移就在所难免。
