composer无一键验证vendor完整性的命令，校验仅在install/update时对dist包执行一次哈希比对，已安装目录不回检；绕过方式多，离线验证需对比installed.json与composer.lock中的dist-sha256字段。
Composer 本身没有一键验证 vendor 文件完整性的命令，所有“校验”都只发生在 install/update 当时，且仅对 dist 包生效；已安装的 vendor 目录默认不被回检，篡改后不会自动报警。
composer install 时的哈希校验只跑一次，且容易被绕过
Composer 在下载 dist 包（zip/tar）后，会比对 composer.lock 中记录的 dist.sha256（或 shasum）与解压前压缩包的实际哈希——但这个动作只在安装/更新那一刻执行，之后就不再复核。
常见绕过场景：
- 本地缓存被污染（如手动修改过
~/.composer/cache/files/下的 zip）→ Composer 复用缓存，跳过哈希比对 - 用了
--prefer-source或"type": "package"→ 完全不读dist.sha256，也不校验哈希 - 国内镜像源未同步原始哈希，或替换了 dist 包 → 哈希值“匹配”，但内容非 Packagist 原始发布版本
- 删了
vendor/后用composer install --no-scripts --no-plugins→ 会跳过部分校验逻辑
vendor/autoload.php 被改了，composer dump-autoload 也不会发现
vendor/autoload.php 只是个固定引导文件，内容就是 require_once __DIR__ . '/composer/autoload_real.php'。它被篡改后，composer dump-autoload 不会读取、比对或报错，因为它只生成 vendor/composer/autoload_*.php 映射文件。
真正危险的是：这个入口文件若被替换成恶意代码（比如加了 eval(file_get_contents(...))），运行时就会触发，而 Composer 完全无感。
防护建议：
- 生产环境把
vendor/设为只读（chmod -R a-w vendor/） - CI 中加一步检查：
grep -q "autoload_real\.php" vendor/autoload.php || exit 1 - 不要依赖
vendor/autoload.php内容不变——它不在任何哈希校验链路里
离线验证 vendor 是否被篡改，得靠 installed.json 和 lock 对比
vendor/composer/installed.json 是 Composer 安装后写入的元数据，里面每个包都带 dist-sha256（或 shasum）字段，理论上应和 composer.lock 中对应包的 dist.sha256 一致。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
这个对比可以离线做，且不依赖网络：
- 用
composer show --installed --format=json提取已安装包的哈希 - 用
composer show --locked --format=json提取 lock 中声明的哈希 - 写个简单脚本（Python/PHP/Shell 均可）做 key-by-key 的
dist-sha256字段比对 - 注意：若项目用了
--prefer-source，则比对的是source-reference（git commit hash），不是dist-sha256
这个方法不校验文件内容是否被删改（比如删掉某个 .php 文件），只确认 installed.json 记录的哈希与 lock 是否一致——但它已是目前最贴近“离线完整性验证”的可行路径。
别信 composer verify-signature，这命令根本不存在
搜索“Composer 签名校验”常看到 composer verify-signature，但截至 Composer 2.7.x（2026 年最新稳定版），**官方从未实现该命令**。所谓“签名”是混淆了两个概念：
- Packagist 对
packages.json元数据做的 GPG 签名 → Composer 可验证（需开启security.signature-verification true），但只防仓库投毒，不校验具体包文件 - 包作者对 zip 包做的 GPG 签名 → Packagist 不提供，Composer 也不支持验证
试图在 composer.json 里加 "signature": "..." 字段，Composer 会直接忽略；第三方插件如 composer-signature-checker 已多年未维护，且在 PHP 8.1+ 上因 openssl_pkey_get_public 废弃而失效。
真正能落地的安全兜底只有三件事：锁死 Packagist 官方源、启用 composer audit 查已知漏洞、CI 中强制 --no-cache --prefer-dist 重装并快照哈希。
哈希校验逻辑本身不复杂，但 Composer 故意没暴露目录级比对能力——因为性能代价太大，也违背“安装即信任”的设计哲学。所以你得自己补这一环，尤其在金融、政企等高敏感场景。
