verify-checksums --strict 报 mismatch 说明该包磁盘文件已被修改，常见原因包括缓存污染、镜像源未同步哈希、手动编辑 vendor 文件或 autoload.php 被篡改。
verify-checksums --strict 报 mismatch 说明什么
它只说明某个已安装包的实际文件内容，和 composer.lock 中记录的 dist.sha256 不一致——不是“可能有问题”，而是“磁盘上这个包肯定被改过了”。常见原因包括：
- 本地缓存曾被污染，
composer install复用了损坏的 zip 包 - 镜像源替换了 dist 文件但没同步哈希值（比如国内镜像未及时更新）
- 手动编辑过
vendor/下的文件（哪怕只是改了注释） -
autoload.php被篡改或重生成——它虽关键，却不在任何dist.sha256记录中，verify-checksums --strict会扫描到它并失败
注意：verify-checksums 不报具体哪个文件出问题，只告诉你包名。要定位，得进 vendor/{vendor}/{package} 目录，用 find . -type f | xargs shasum -a 256 | shasum -a 256 手动归并比对。
composer validate 通过 ≠ 依赖能装上
composer validate 只检查 composer.json 的 JSON 语法和字段合法性，完全不碰网络、不查 Packagist、不验证版本是否存在。所以：
-
"require": {"nonexistent/package": "dev-main"}→validate通过，install必炸 -
"php": ">=8.3"写得再规范，PHP 8.2 环境下install仍失败 - 缺
"description"字段 → 默认只警告，加--strict才报错；CI 中必须用composer validate --strict --no-check-publish
真正校验 vendor 文件是否和 lock 一致，只能靠 COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict，validate 完全不读 vendor 目录。
audit 和 outdated --all 各管一段，缺一不可
composer audit 查的是已安装包是否在 FriendsOfPHP/security-advisories 库里有已知漏洞，但它：
- 默认跳过
require-dev下的包（如phpunit/phpunit），需显式加--dev - 不识别 EOL 包、不分析运行时行为、不扫描源码
- 不告诉你升完会不会坏——得靠
composer outdated --all看可升级项，再用composer update --dry-run -v推演 solver 行为
比如 --dry-run 输出里出现 guzzlehttp/guzzle 7.4.5 → 7.5.0 !，那个 ! 就代表已知 BC-breaking；若顺带把 psr/http-client 从 1.x 升到 2.x，你所有 sendRequest() 调用就直接崩。
最危险的校验盲区是 autoload.php
verify-checksums --strict 会扫描 vendor/autoload.php，但它没有对应哈希记录，所以只要内容变了就报 mismatch；而更糟的是：如果它没被扫描到（比如被排除规则误跳过），或者你用的是 --prefer-source 安装，那它就彻底游离在校验体系外。
生产部署前必须做两件事：
- 设
vendor/为只读（chmod -R a-w vendor/） - 单独断言
vendor/autoload.php的内容未变，比如用sha256sum vendor/autoload.php和预存值比对
别指望 composer install 或 --dry-run 能发现它被注入恶意代码——它们根本不校验这个文件。
