根本没法跳过；Composer 设计上强制要求 vendor 目录与 composer.lock 严格一致，每次 install 都会校验并拒绝使用不一致的 vendor，不存在官方支持的跳过方式。
Composer install 时如何跳过 vendor 完整性校验
默认情况下，composer install 会检查 vendor/ 目录是否与 composer.lock 一致，不一致就强制重装——这不是“检测完整性”，而是“拒绝使用不一致的 vendor”。真要跳过这个行为，用 --no-scripts --no-plugins --ignore-platform-reqs 没用，关键参数是 --no-install？不对，那是完全不装。真正生效的是：--prefer-dist 不影响校验，--dry-run 只模拟。唯一绕过校验的方式是加 --no-dev 同时删掉 vendor/ 里的 dev 包？也不对。
答案是：**根本没法跳过**。Composer 设计上就不允许你“信任现有 vendor 并继续”。它认为 vendor 目录一旦存在且 lock 文件也存在，就必须严格匹配。所以所谓“自动检测完整性”，其实是每次 install 都在做——只是你不感知而已。
用 composer show --installed 验证 vendor 是否缺失包
composer show --installed 会列出当前 vendor/ 中实际加载的包及其版本，但它不报错、不对比 lock，只是 dump 列表。想靠它“检测完整性”得自己写比对逻辑：
- 先运行
composer show --installed --format=json > installed.json - 再解析
composer.lock，提取所有packages和packages-dev的 name + version - 逐个检查这些包是否出现在
installed.json中，路径是否存在（如vendor/foo/bar）
注意：composer show --installed 不显示被 replace 或 provide 掩盖的包；若用了 path repository，它显示的是源路径而非 vendor 下 symlink，容易误判为“缺失”。
通过 composer status 发现未提交的本地修改
composer status 是最接近“完整性检测”的内置命令：它扫描 vendor/ 下每个包的源码目录，用 git status（或 hg status）检查是否有未提交修改、未跟踪文件或切换了分支。这不检测“包是否少”，而检测“包是否被手改过”。
常见误用场景：
- CI 环境里没装 git，
composer status直接报错退出，不是返回非零码而是 PHP Warning - 包用的是
dist方式安装（zip/tar），没有 .git 目录，status会跳过——它只对source有效 - 输出里出现
??行不代表损坏，只是多了临时文件；但M（modified）或DU（deleted/updated）才真正危险
建议在部署后跑一次：composer status --verbose 2>/dev/null | grep -E '^??|^M|^DU' || echo "clean"，但别把它当 vendor 存在性断言。
自定义脚本检查 vendor/autoload.php 和类加载器
最务实的“完整性”判断，其实是看能不能干活：vendor/autoload.php 是否可 require？核心类（如 PsrContainerContainerInterface）能否成功 class_exists()？
写个最小验证脚本 check-vendor.php：
#!/usr/bin/env php
<?php if (!file_exists('vendor/autoload.php')) {
die("vendor/autoload.php missing
");
}
require 'vendor/autoload.php';
if (!class_exists('Psr\Log\LoggerInterface')) {
die("Psr\Log\LoggerInterface not loadable
");
}
echo "OK
";
这个检查快、无依赖、能捕获 autoload 失败、符号链接断裂、opcache 缓存旧路径等问题。比任何静态扫描都可靠——但注意：它不保证所有 dev 包都齐（比如 phpunit 不在 autoload 里），所以生产环境用，CI 流水线里建议额外加 composer show --installed | wc -l 和 lock 文件里的包数比对。
vendor 目录的“完整”没有绝对标准，lock 文件、autoload、git 状态、磁盘路径四者视角不同；自动检测必须明确你究竟防什么：是防 CI 缓存污染？防开发者误删？还是防部署中断导致部分包写入失败？选错检测点，脚本写得再全也没用。
