composer validate 默认仅校验 JSON 语法和基础 schema，不检查字段语义、依赖兼容性或目录存在性；加 --strict 可启用严格模式，捕获拼写错误、弃用字段等，CI/CD 中应强制使用并配合 --dry-run 验证依赖。
composer validate 能检查 composer.json 是否符合 JSON 语法和 Composer 的 schema 规范，但默认不校验字段语义（比如写错 autoload 类型不会报错），得加 --strict 才能触发完整校验。
composer validate 报 JSON decode error 怎么快速定位
这是最常见也最烦人的错误——不是 schema 不对，是 JSON 本身写坏了。Composer 不会告诉你哪一行出问题，得自己排查：
- 用
jq . composer.json（需安装jq）：直接解析，失败时会输出具体行号和列号 - 复制内容到 VS Code 或其他编辑器里，看有没有高亮标红的语法错误（比如末尾多逗号、单引号代替双引号、中文标点）
- 注意隐藏字符：从网页复制过来的
composer.json可能含零宽空格（u200b），用cat -A composer.json查看
为什么 composer validate 通过了，但 composer install 还报错
因为 validate 默认只做基础校验，不检查依赖兼容性或字段逻辑合法性。例如：
-
"require": {"php": ">=8.0"}语法合法，但若你本地是 PHP 7.4，install仍会失败 -
"autoload": {"psr-4": {"Foo\": "src/"}}格式正确，但如果src/目录不存在，dump-autoload会警告，validate却不吭声 - 使用了已废弃字段如
archive或拼错字段名（requrie），validate默认也不报
解决办法：加上 --strict 参数，它会启用更严格的 schema 检查，捕获更多拼写和弃用问题。
CI/CD 里怎么用 composer validate 避免低级失误
在 GitHub Actions 或 GitLab CI 中，别只跑 composer validate，容易漏掉关键问题：
- 固定加
--strict：防止字段拼写错误或过时配置被忽略 - 配合
composer install --dry-run：验证依赖可解析且无冲突（比validate更贴近真实执行） - 如果项目支持多 PHP 版本，记得在对应 PHP 环境下运行（
validate本身不依赖 PHP 版本，但--strict下某些字段校验会参考当前 Composer 版本的 schema） - 别把
composer.json和composer.lock分开校验——lock文件损坏不会被validate发现，要用composer install --no-install或composer lock --check（Composer 2.2+）
真正卡住人的往往不是语法错误，而是 validate 默认太宽容，让人误以为“过了就稳了”。加 --strict 是最低成本的防御手段，但别指望它替代手动读一遍 require 和 autoload 配置。
