composer validate 主要检查 composer.json 的 JSON 语法正确性及 Composer schema 合规性，如 name 缺失、version 格式错误、require 包名含非法字符等，但不验证包存在性、可安装性或 lock 文件同步性。
composer validate 会检查哪些问题
它主要验证 composer.json 文件是否符合 JSON 语法，以及是否满足 Composer 的 schema 规范——比如 name 字段是否缺失、version 是否用了非法格式（如 1.0.0-beta 写成 1.0.0beta）、require 下的包名是否包含非法字符等。
注意：它不检查包是否存在、版本是否可安装，也不校验 composer.lock 是否与 composer.json 同步。
什么时候必须运行 composer validate
在以下场景建议手动执行：
- 修改完
composer.json后提交前（CI 中常作为 lint 步骤） - 从别人那里复制了配置片段，不确定格式是否合规
-
composer install或composer update报错提示 “Invalid argument” 或 “Could not parse …” 时，优先用它定位是不是 JSON 结构或字段写错了
常见误报和容易忽略的细节
它默认只校验当前目录下的 composer.json，不会递归检查子目录；如果项目含多个 composer.json（如 monorepo），需手动指定路径：
composer validate path/to/another/composer.json
另外，默认启用严格模式（--strict），会把警告（如缺少 description）也当作错误。若想只看硬性错误，加 --no-check-all 或显式关闭严格模式：
composer validate --no-check-publish --no-check-lock
还有个坑：Windows 下用 Git Bash 运行时，若 composer.json 末尾多了 BOM 头，validate 会直接报“Syntax error”，但错误信息不提示 BOM，得靠编辑器查编码。
和 composer install --dry-run 不是一回事
composer validate 是纯静态检查，不联网、不读仓库、不解析依赖图；而 composer install --dry-run 会模拟安装全过程，包括版本约束求解、平台配置兼容性、甚至远程包元数据获取。两者目标完全不同，不能互相替代。
真正容易被跳过的，是把 validate 当成“确保能装上”的手段——它连 php: ^8.1 和当前 PHP 版本是否匹配都不管，那块得靠 composer check-platform-reqs。
