校验和冲突是 Composer 下载包时 dist.sha256 与 composer.lock 不匹配导致的下载失败，非文件损坏；常见于镜像缓存旧版、tag 重推、私有源不一致或代理篡改；须清空 vendor 和 composer.lock 并切换至官方源重装。
校验和冲突不是文件损坏，是 Composer 下载的包与 composer.lock 记录的 dist.sha256 对不上——它拒绝加载，不是因为 vendor 被改了，而是下载环节就失败了。
为什么 composer install 突然报 Checksum mismatch
这个错误发生在下载阶段，Composer 拿到 zip 包后立刻比对哈希值，不匹配就中止。常见原因有：
- 你用的是国内镜像（如阿里云），但该镜像缓存了旧版包，而
composer.lock里记录的是新版 tag 重推后的哈希 - 包作者删了 tag 又重推（比如修复安全问题后强制覆盖 v2.1.0），但 lock 文件仍指向旧哈希
- 私有仓库（
repositories中 type:vcs或package）返回的 dist URL 和 checksum 与 packagist.org 不一致 - 代理或企业 CDN 在传输中修改了响应体（极少见，但 CI 日志里能看到 Content-Length 变化）
别只删 vendor/，必须连 composer.lock 一起清
只删 vendor/ 再跑 composer install，会复用旧 lock 里的错误哈希，错误必然重现。正确做法是：
- 执行
rm -rf vendor composer.lock（Windows 用rd /s /q vendor & del composer.lock） - 确认源干净：
composer config -g --unset repos.packagist，再composer config -g repo.packagist composer https://packagist.org - 运行
composer install—— 它会重新拉取元数据、生成新 lock，所有哈希从头计算 - 如果必须用镜像，等同步完成（阿里云通常 10–30 分钟），不要在同步中途切回
composer why-not 查不到校验和问题的根源
composer why-not 解决的是依赖图层面的版本冲突，不是哈希校验失败。它对 Checksum mismatch 完全无响应，因为错误发生在解析依赖树之前。此时：
- 运行
composer config repositories检查是否注册了可疑的私有源 - 执行
composer show --locked | head -20看报错包是否出现在 lock 列表中；如果没出现，说明它根本没进依赖树，不是why-not的管辖范围 - 临时加
COMPOSER_DISABLE_CHECKSUM_VERIFY=1 composer install可绕过（仅调试），但该变量在 Composer 2.2+ 已被标记为 deprecated，且下次不带变量仍会失败
CI 构建后 vendor 被篡改？Composer 根本不校验
composer.lock 里的 dist.sha256 只在下载时用一次，装完就丢。它不校验 vendor/ 里任何已安装文件——包括 vendor/autoload.php 这种高危入口文件。这意味着：
- CI 构建完成后若允许写
vendor/，攻击者可直接覆盖autoload.php插入恶意代码，Composer 零感知 - 生产环境必须设
vendor/为只读：chmod -R 555 vendor/或容器中启用readonlyRootFilesystem: true - 检测脚本里应单独固化关键文件哈希，例如：
[[ $(sha256sum vendor/autoload.php | cut -d' ' -f1) == "b0e4a7c9..." ]] || echo "tampered!"
校验和冲突的本质是信任链断裂，不是缓存脏了就能刷掉。真正要盯住的，是 lock 文件来源是否可信、镜像是否滞后、私有源是否自洽——而不是反复重试 install。
