composer validate 仅校验 JSON 语法和字段结构，不解析依赖关系或验证包存在性与版本兼容性；真正检测依赖可行性需用 composer install --dry-run 或 composer diagnose 等命令。
composer validate 为什么有时“验不出错”，install 却失败？
因为 composer validate 只校验 JSON 语法和字段结构，不解析依赖关系。它不会检查 "require": {"monolog/monolog": "999.0.0"} 这种包是否存在，也不会判断 "^8.0 || ^9.0" 是否能被满足——这些要等 composer install 或 composer update 启动依赖求解器时才暴露。
常见现象：validate 显示 ./composer.json is valid，但紧接着 run composer install 就报 Could not find package xxx 或 Version conflict。
-
composer validate不读取 Packagist，不联网查包名，不验证版本约束语义 - 真正做版本兼容性分析的是
composer install --dry-run，它会模拟安装全过程，推荐在 CI 中补上这步 - 如果你改过
composer.lock手动，validate完全不关心；要用composer validate --lock才校验 lock 与 json 是否匹配
怎么快速定位 JSON 语法错误（比如 trailing comma）？
错误提示里常出现 [Syntax Error] JSON error: Parse error on line 12，但编辑器行号可能不准——尤其当文件含 BOM、混合换行符（\r\n）、或你用 AI 生成后没清理注释时。
- 先用
php -l composer.json快速过一遍：PHP 自带 JSON 解析器对格式更敏感，且报错更准 - 粘贴内容到 JSONLint，它会高亮非法字符（如单引号、末尾逗号、未转义反斜杠）
- VS Code 用户装
JSON Tools插件，右键选Prettify JSON，自动修复缩进+补引号（但注释得手动删） - 注意：JSON 不允许注释（
//或/* */），也不接受未加引号的键名，php: "^8.1"❌ 必须写成"php": "^8.1"✅
--strict 到底严格在哪？什么时候该加？
--strict 不是让语法检查更“严”，而是把原本只是警告的内容（比如缺 description、license 字段）当成错误处理，命令返回非零退出码。这对 CI/CD 很关键，但本地开发中容易误伤。
- CI 脚本里建议用：
composer validate --strict --no-check-publish，跳过 Packagist 发布校验（避免网络超时中断流程） -
--no-check-publish关键：它禁用对name是否符合命名规范、license是否为 SPDX 标准值等发布前检查 - 不加
--strict时，缺description只会警告；加了就直接失败，适合团队统一规范，但别在还没定稿的私有项目里硬套 -
composer validate --lock和--strict可共存，但二者目标不同：前者保一致性，后者保完整性
除了 validate，还有哪些命令能交叉验证？
单靠 composer validate 不足以保障配置可用。它像体检报告里的“血常规”，正常不代表没病；真要确认依赖能装、环境能跑，得看“CT”。
-
composer diagnose：查环境问题，比如 PHP 版本、扩展是否启用、CA 证书路径是否可读——很多 “validate 通过但 install 失败” 其实是这一步卡住 -
composer install --dry-run --no-interaction：最接近真实安装的模拟，会校验平台配置（如platform.php）、依赖可解析性、autoload 映射合法性 -
composer show --tree（需已 install）：反向验证 autoload 是否生效，比如psr-4映射的命名空间是否真能加载类 - 线上工具辅助：用 Online Composer Validator 粘贴内容，它比本地 validate 多一层 schema 校验（比如
type字段是否在白名单中）
真正复杂的地方不在 validate 命令本身，而在于它只负责“格式合规”，不负责“语义可行”。很多人卡在 install 阶段才发现 require 写错了包名，其实早该用 --dry-run 多走一步。
