需手动校验：读取 composer.lock 中的 dist.sha256，下载原始包、解压后计算目录哈希并比对；生产环境应设 vendor/ 为只读，CI 中推荐用 tar 哈希快照比对（排除 vendor/bin/ 和 installed.json）。
composer install 时没报错，但怎么确认 vendor 里的文件没被篡改？
Composer 本身不校验已安装包的文件哈希，composer install 或 composer update 后，vendor 目录内容就“静态落地”了——除非你主动启用验证机制，否则它不会回头检查 vendor/ 里某个 autoload.php 是否被悄悄替换成恶意版本。
真正起作用的是 composer install --dry-run + composer validate 的组合，但它们都不校验文件。要验完整性，得靠 composer show --locked 对应的锁文件 + 外部工具，或者启用 Composer 内置的 verify-signature（仅限签名包）。
-
composer.lock记录了每个包的dist.sha256（或sha1），这是下载时校验用的，但只在安装/更新当时生效；重装后不自动复核 - 没有全局开关让 Composer 每次加载都重新 hash 所有 vendor 文件——性能和设计上都不支持
- 如果你用的是 Packagist 官方源且包启用了签名（如 Laravel、Symfony 官方包），可开启
composer config -g security.signature-verification true，但这只验证包分发时的 GPG 签名，不是运行时文件比对
如何手动触发一次 vendor 文件与 lock 文件的 SHA 校验？
没有现成命令一键跑完所有包的哈希比对，但可以用 composer show --locked --format=json 提取哈希，再配合脚本逐个比对 vendor/ 下对应 dist 归档解压后的实际文件。更现实的做法是借助社区工具：
- 用
composer-require-checker不行——它只查未声明的函数调用，不碰文件完整性 - 推荐
roave/security-advisories配合composer audit（Composer 2.5+）：它不验哈希，但能识别已知漏洞版本，属于间接安全兜底 - 真正做文件级校验，得自己写小脚本：读
composer.lock→ 提取每个包的dist.sha256和dist.url→ 下载原始 zip → 解压 → 计算目录整体哈希（注意排除.git、tests/等非发布文件）→ 对比。这很重，一般只在 CI 中做快照比对
为什么 vendor/autoload.php 被改了，composer dump-autoload 却不报错？
composer dump-autoload 只重新生成自动加载映射（vendor/composer/autoload_*.php），完全不读取或校验 vendor/autoload.php 本身的内容。而这个文件只是个引导入口，内容固定，被篡改后也不会触发任何警告。
- 它默认内容就是
require_once __DIR__ . '/composer/autoload_real.php';，改掉这行或插入恶意代码，Composer 全程无感 - 真正该监控的是
vendor/composer/installed.json和vendor/composer/autoload_static.php这类生成文件——但 Composer 不提供校验 API - 生产环境建议把
vendor/设为只读（chmod -R a-w vendor/），至少防住低权限篡改
CI/CD 中最轻量又靠谱的完整性检查怎么做？
别指望 Composer 自己完成，直接在 CI 脚本里加一步：比对当前 vendor/ 和上次已知干净快照的 tarball 哈希。不需要还原整个流程，只要保留一个 clean-vendor.tar.gz 就行。
- 构建开始前：用
tar -cf - vendor/ | sha256sum得到当前哈希 - 对比预存的 clean-vendor.sha256，不一致就 fail —— 注意排除
vendor/bin/（可能含本地软链）和vendor/composer/installed.json（含时间戳） - 如果用 GitHub Actions，可用
actions/cache缓存 clean-vendor.tar.gz，并在每次构建后更新缓存（带条件：仅当composer.lock变更） - 别用
composer update --lock当校验手段——它只会按 lock 重装，不告诉你哪几个文件多出来或少掉了
真正难防的是供应链投毒：攻击者先污染 packagist.org 上的包元数据，再等你 composer update 拉下来。这时候 lock 文件哈希也“合法”，但源头已坏——这种只能靠人工审计依赖树、限制包来源（如只允许 org:laravel）、或用 SCA 工具扫描。
