composer validate 不支持 --with-dependencies 参数，仅校验当前项目 composer.json；验证依赖需手动遍历 vendor 目录下各包的 composer.json 并执行 validate。
composer validate 本身不支持 --with-dependencies 参数
执行 composer validate --with-dependencies 会直接报错：Unrecognized option: --with-dependencies。Composer 官方 CLI 的 validate 命令**没有这个参数**，它只校验当前项目的 composer.json 格式、必需字段、schema 合规性等，不会加载或检查依赖包的 composer.json。
想验证依赖包的 composer.json，得手动进入 vendor 目录逐个跑
如果你确实需要检查已安装依赖的清单是否合法（比如 CI 中防劣质第三方包），只能自己遍历 vendor/ 下每个包的 composer.json 并调用 composer validate：
- 先确保已安装依赖：
composer install - 用 shell 脚本遍历（Linux/macOS）：
find vendor -name 'composer.json' -not -path 'vendor/composer/*' -exec echo "Validating {}" \; -exec composer validate --no-check-publish --no-check-all {} \; - Windows 用户可用 PowerShell 或
forfiles，但注意路径转义和vendor/composer/是 Composer 自身元数据，必须跳过 -
--no-check-publish跳过对publish字段的校验（避免因未登录 Packagist 报错） -
--no-check-all禁用所有可选检查（如 license 是否在 SPDX 列表中），聚焦基础 schema
更现实的做法：靠 lock 文件 + require-dev + CI 约束
真正影响项目稳定性的不是单个依赖的 composer.json 是否“格式正确”，而是：composer.lock 是否完整、require-dev 是否被误提 prod、是否有冲突的 PHP 版本约束。因此实际工程中更推荐：
- CI 中强制运行
composer validate --strict（校验composer.json的完整性与规范性） - 运行
composer install --dry-run检查依赖解析是否仍可行（隐式验证 lock 与 json 一致性） - 用
composer show --tree快速人工抽查关键依赖的版本链路 - 对高风险依赖（如 fork 包、无维护者包），单独加脚本检查其
composer.json的autoload和require字段是否合理
别被“全面验证”误导，Composer 的设计哲学是信任 lock
Composer 不提供连带验证依赖的开关，是因为它把“依赖可信”这件事交给了 packagist.org 的审核机制、lock 文件的确定性，以及开发者对 require 版本范围的谨慎选择。强行递归验证 vendor 里的几百个 composer.json，不仅慢、易失败（很多小包 schema 过旧或含非标字段），还掩盖了真正该关注的问题——比如某个依赖悄悄改了 autoload 导致类找不到，这靠 validate 发现不了，得靠测试和 composer dump-autoload -o 后运行时检验。
