composer validate 主要检查 composer.json 的 JSON 语法及 Composer schema 规范，如 name 格式、version 合法性、require 包名结构、psr-4 路径结尾等；默认不校验依赖可安装性或 lock 文件，除非加 --locked。
composer validate 会检查哪些问题
composer validate 不只是校验 JSON 语法是否合法，它还会验证 composer.json 是否符合 Composer 的 schema 规范。比如：name 字段是否包含斜杠、version 是否用了非法字符、require 里有没有写错的包名格式（如 vendor/name 缺少斜杠）、autoload 中的 psr-4 映射路径是否以反斜杠结尾等。
它默认不检查依赖能否实际安装（那是 composer install 干的事），也不校验锁文件——除非你加 --locked 参数。
运行 validate 的常见方式和参数差异
最基础用法就是当前目录下执行：
composer validate
但容易忽略几个关键选项：
-
--no-check-all：跳过对所有已知 package name 的远程校验（比如确认monolog/monolog确实存在），加快速度，适合 CI 环境 -
--strict：把警告（warning）也当作错误（error）处理，CI 中建议加上，避免低风险问题被忽略 -
--locked：同时校验composer.lock是否与composer.json一致，防止手动改了 json 却没更新 lock -
-v或--verbose：显示具体哪一行、哪个字段出问题，尤其对嵌套深的 autoload 配置有用
为什么有时 validate 通过了，install 却失败
这是高频困惑点。composer validate 只管结构合规，不管语义可行。以下情况都会导致 validate 成功但 install 失败：
-
require里写了不存在的版本约束，比如"php": ">=8.4"（当前还没发布） -
conflict或replace写法逻辑矛盾，但 schema 层不报错 -
repositories中自定义源地址不可达，或返回非标准响应 -
autoload-dev引用了未声明的命名空间路径，PHP 自动加载时才暴露
换句话说：validate 是“语法+结构体检”，install 才是“功能压力测试”。
CI/CD 中怎么稳妥地集成 validate
在 GitHub Actions、GitLab CI 这类环境里，别只跑 composer validate 就完事。推荐组合使用：
- 先
composer validate --strict --no-check-all快速过格式 - 再
composer install --dry-run --no-interaction模拟安装，能提前发现版本冲突、平台要求不满足等问题 - 如果项目有 lock 文件，加
--locked；如果没有（比如库项目），记得在 workflow 中禁用 lock 校验，否则会报错
特别注意：某些旧版 Composer（--locked 支持不全，遇到 Invalid argument supplied for foreach() 类错误，先升级 composer self-update。
