composer validate 仅校验 composer.json 的 JSON 合法性与结构合规性，不检查依赖可行性；真正验证依赖需用 composer install --dry-run。
composer validate 不能保证 install 成功，它只管 JSON 是否合法、字段是否拼对、结构是否合规——真正的依赖可行性得靠 composer install --dry-run。
composer validate 报错但没给行号？先看错误信息里的 line/column
Composer 不会说“你少了个逗号”，而是抛出类似 JSON parse error on line 23 at column 17。这个位置就是问题源头，别从头重写文件。
- 用 VS Code 或 Vim 打开
composer.json，按Ctrl+G（或Cmd+G）跳转到第 23 行，把光标移到第 17 列附近 - 重点查：末尾多出的逗号（尤其在对象最后一项后）、中文标点（如全角
，或：）、单引号代替双引号、粘贴进来的// 注释（JSON 不支持） - 右下角确认编码是
UTF-8，不是UTF-8 with BOM——Windows 记事本保存极易带 BOM，导致解析失败
validate 通过了，install 却报包不存在或版本冲突？这是正常现象
composer validate 完全不联网、不查 Packagist、不解析版本约束语义。它认可 "monolog/monolog": "999.0.0" 是合法字符串，但 install 时才发现这版本根本不存在。
- 真正暴露依赖问题的是：
composer install --dry-run（Composer 2.5+ 稳定支持） - 它会完整走一遍依赖求解流程：读
composer.lock或重新计算依赖图、检查平台约束（PHP 版本、扩展）、识别冲突，但不下载任何包 - CI 中建议组合使用：
composer validate --strict --no-check-publish && composer install --dry-run --no-interaction
--strict 和 --lock 不是可选项，是关键控制点
--strict 不是“更严一点”，而是启用完整 JSON Schema 校验 + 额外语义检查；--lock 不是“顺便看看”，而是验证 composer.lock 是否真由当前 composer.json 生成。
-
composer validate --strict会拒绝"name": "myapp"（缺 vendor/ 前缀）、"autoload": {"psr-4": {"App\": "src//"}}（路径末尾双斜杠）、"config": {"allow-plugins": true}（老版本 Composer 不认识该字段） -
composer validate --lock会比对composer.json的 hash 与composer.lock中记录的 hash 是否一致，防止手动改 json 后忘了update --lock - 注意：
--dry-run在旧版 Composer 中可能跳过某些校验，生产环境 CI 应明确锁定 Composer 版本（如2.7.7）
最常被忽略的一点：validate 和 --dry-run 都不校验 vendor 目录里文件是否被篡改或缺失——它们只管配置和依赖逻辑。要验文件完整性，得靠锁文件中的 dist.sha256 + 外部工具比对，或者重装整个 vendor。
