composer validate 是校验 composer.json 语法最轻量可靠的方式，仅静态检查 JSON 结构、字段合法性及版本约束格式，不联网、不读 vendor；加 --strict 可拦截拼错字段等语义错误，CI 中应固定使用 composer validate --no-interaction --strict。
直接用 composer validate 检查 composer.json 语法
最轻量、最可靠的方式就是运行 composer validate，它会校验 JSON 结构、字段合法性、版本约束格式（比如 ^2.5 是否被支持）、以及 repository URL 是否以 / 结尾等硬性规则。不下载任何包，不读取 vendor，纯静态检查。
常见错误现象：composer install 报 Your requirements could not be resolved，但其实根本没走到依赖解析那步——composer.json 里多了一个逗号、少了一个引号，或用了 "type": "package" 却漏写 "dist" 字段，validate 会立刻指出具体行号和原因。
- 加
--strict开启严格模式：拒绝过时字段（如require-dev写在根级但项目没启用 dev 模式） - CI 流水线中建议固定命令：
composer validate --no-interaction --strict，避免交互提示中断流程 - 注意：它不检查 PHP 代码语法（比如
scripts里写的 PHP 回调），只管 JSON 和 Composer 协议层
scripts 字段里的 PHP 代码怎么提前发现语法错误
composer.json 的 scripts 里如果写了内联 PHP（如 "post-install-cmd": ["php -r 'echo \"hello\";'"]），validate 是不管的。这类错误只有执行时才暴露，但你可以用 php -l 提前扫。
实操建议：
- 把内联脚本抽成独立文件（比如
scripts/check-env.php），然后在scripts中引用："pre-install-cmd": "php scripts/check-env.php" - 对这类文件单独做语法检查：
php -l scripts/check-env.php，失败时返回非零码，可集成进 pre-commit hook - 如果必须写内联，用
php -r手动试跑一次：php -r "echo 'test';"，确认引号转义和分号位置没出错
为什么 composer install --dry-run 不是语法检查的替代方案
composer install --dry-run 看起来“不真装”，但它仍会走完整解析流程：加载 vendor/autoload.php、读取所有 repositories、尝试匹配每个包的 version constraint。一旦镜像源不可达、PHP 扩展缺失（如 ext-zip）、或 autoload 配置有误，它就会卡住或报错——这些都不是语法问题，而是环境或配置问题。
容易踩的坑：
- 误以为
--dry-run成功 =composer.json没问题，结果上线后因镜像临时故障导致 CI 失败 - 本地
--dry-run过了，但 CI 里用的是旧版 Composer（如 2.2.22），它根本不认识^2.5，直接退出且不报具体哪行错 - 它不会告诉你
"config": {"fxp-asset": {...}}这种已废弃字段是否还在用
复杂点在于嵌套结构和条件字段
像 conflict、provide、replace 这些字段本身合法，但组合使用时可能触发隐式冲突；autoload 下的 psr-4 映射若路径含 ../ 或结尾没加 /，validate 未必报错，但 composer dump-autoload 会失败。
真正要覆盖全，得配合两步：
- 先
composer validate --strict过基础语法 - 再
composer dump-autoload --no-scripts --dry-run验证自动加载部分是否可生成（不执行脚本，避免副作用）
这两步加起来不到 1 秒，比等 install 卡在“Resolving dependencies”阶段强得多。
