verify-checksums 是 Composer 2.5+ 实验性命令，需 ≥2.5 版本并设置 COMPOSER_EXPERIMENTAL=1 启用；它真实校验 vendor 文件 SHA256 值与 composer.lock 是否一致，是上线前防篡改的关键防线。
composer verify-checksums 为什么总报错“Command not found”
因为 verify-checksums 是 Composer 2.5+ 的实验性命令，默认不启用，不是所有安装包都带它。你执行失败，大概率是版本不够或没开启实验功能。
实操建议：
- 先运行
composer --version确认 ≥ 2.5；低于就升级：composer self-update - 检查是否启用了实验命令：运行
composer list | grep verify，没输出说明被禁用 - 启用方式是设置环境变量：
COMPOSER_EXPERIMENTAL=1 composer verify-checksums - CI/CD 脚本里别漏掉这个前缀，否则部署时静默跳过，等于没验
verify-checksums 和 install --dry-run 本质区别在哪
install --dry-run 只模拟依赖解析和下载逻辑，不校验已安装包的文件内容；而 verify-checksums 是真读取 vendor/ 下每个包的 composer.lock 记录的 SHA256 值，逐个比对磁盘文件——这才是防篡改、防损坏的关键。
使用场景很明确：上线前最后一道防线，尤其在共享构建机、容器镜像复用、或手动改过 vendor 的环境里必须跑。
注意点：
- 它不联网，只校验本地
vendor和composer.lock是否一致 - 如果 lock 文件被人工修改过（比如删了 checksum 字段），会直接报错退出，不是警告
- 不校验
autoload生成的文件，也不管post-install-cmd脚本有没有副作用
CI 中集成 verify-checksums 的安全写法
不能只在 composer install 后加一句 composer verify-checksums 就完事。很多 CI 镜像默认没开实验功能，且错误码容易被忽略。
推荐写法（以 GitHub Actions 为例）：
COMPOSER_EXPERIMENTAL=1 composer install --no-interaction --no-progress COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict
--strict 很关键：它让命令在发现任何 checksum 不匹配时返回非零退出码，确保 pipeline 失败而不是继续部署。
容易踩的坑：
- 没加
--strict，默认只是 warn 并返回 0，CI 以为成功了 - 把
COMPOSER_EXPERIMENTAL=1写在不同行，bash 不继承环境变量，第二行失效 - 在 Docker 构建中用了多阶段，
verify-checksums跑在 builder 阶段，但实际运行时vendor被复制过去后可能被覆盖或权限变更，校验失效
verify-checksums 报 “Checksum mismatch” 怎么快速定位
错误信息形如：Checksum mismatch for package foo/bar (expected xxx, got yyy)，但它不告诉你具体哪个文件坏了。
调试步骤：
- 先确认是不是误改：用
git status vendor/看是否有未提交变更 - 查 lock 文件里该包的 checksum 记录：
grep -A 5 '"foo/bar":' composer.lock | grep checksum - 手动计算当前文件哈希：
find vendor/foo/bar -type f -exec sha256sum {} \; | sha256sum（注意路径和 lock 中的 package 名是否完全一致） - 常见元凶：IDE 自动格式化、.gitattributes 换行符转换、部署脚本里 sed 替换了 vendor 中的配置文件
真正难处理的是那些“合法但不可重现”的修改——比如某个包的 post-install-cmd 动态生成了文件却没更新 lock，这种就得从源头约束脚本行为，而不是指望 verify-checksums 善后。
