validate只校验composer.json语法与字段合法性（需--strict生效），verify-checksums--strict才是唯一校验vendor文件实际SHA256哈希的命令，二者对象、时机、范围均不同。
Composer 本身没有“数据校验”命令——你真正需要的，是针对不同对象（composer.json、composer.lock、vendor/ 文件）分别调用对应命令，并理解它们各自校验什么、不校验什么。
validate：只管 JSON 写得对不对，不管包存不存在
composer validate 是唯一内置的格式校验命令，但它只做两件事：解析 JSON 语法 + 检查字段结构合法性（加 --strict 才生效）。它完全不联网、不读 vendor/、不验证 autoload 路径是否存在。
- 报
JSON parse error？直接跳到错误提示里的行号和列号（如line 12 at column 5），盯末尾逗号、单引号、BOM 头或全角符号 - 想让 CI 真正拦住低级错误（比如拼错
autoload字段、漏description），必须加--strict；否则只是警告 - CI 中推荐固定用：
composer validate --strict --no-check-publish，跳过 Packagist 发布检查，避免网络失败中断流程 - 即使
validate通过，composer install仍可能失败：比如"require": {"nonexistent/package": "dev-main"}合法但不可安装
verify-checksums --strict：唯一能校验 vendor 文件真实哈希的命令
它不是默认开启的，也不是“装完就自动跑”的功能。它是实验性命令，必须显式启用，且只在校验解压落地后的文件实体。
- 必须前置设置：
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict；不加--strict会静默警告并返回 0，CI 会误判成功 - 它扫描
vendor/下每个包的实际文件（跳过.git、tests/），归并字节流算 SHA256，与composer.lock中的dist.sha256比对 - 不校验
vendor/composer/autoload_*.php这类生成文件，也不校验type: "path"的本地包——这些是盲区，需手动防护 -
composer install成功 ≠verify-checksums通过：前者只校验下载包解压前的哈希；后者校验的是磁盘上已写入的文件，CI 中若用了--prefer-source或污染缓存，这里最容易暴露问题
audit：依赖 FriendsOfPHP 安全数据库，只扫 lock 文件里的精确版本
它不分析代码、不查私有包、不运行任何脚本，纯粹是“查表比对”。能用的前提非常硬：
- Composer 版本 ≥ 2.5.0，且全局启用：
composer config --global experimental.audit true - 项目必须存在有效的
composer.lock（CI 中不能跳过composer install直接跑） - 输出空或报
Could not find composer.lock，说明锁文件缺失、未更新，或命令根本没注册成功（composer list | grep audit可验证） - 加
--format=json --with-dev --severity=critical,high才适合 CI 门禁；--fixed能直接给出修复版本，比看文档快得多
别混淆“校验”和“验证逻辑”：Excel 表格、API 请求体不是 Composer 的事
看到“批量导入表格校验”“API 参数类型校验”，别指望 composer 命令能解决——那是你项目里 Validator::make()、phpexperts/datatype-validator 或自定义规则的事。Composer 只管自身生态的元数据和文件完整性。
最常被忽略的一点：autoload.php 和所有生成文件完全游离在校验体系之外。哪怕 verify-checksums 和 audit 全部通过，攻击者只要篡改了 vendor/autoload.php，整个应用入口就已被控制。
