composer install 不校验 composer.json 架构合法性，仅基础解析；真正执行 JSON Schema 和字段语义校验的唯一命令是 composer validate，且需加 --strict 才将拼写错误、弃用值等转为硬性错误。
Composer 安装过程本身 不校验 composer.json 的架构合法性 —— 它只在执行 composer validate 时才做这件事。
composer install 会读取但不校验 JSON 结构
composer install 的第一件事是解析 composer.json，但它不会像 validate 那样走完整 JSON Schema 校验流程。它只做最基础的 JSON 解析（用 PHP 原生 json_decode()），失败则报 JSON parse error；成功就继续往下走，哪怕字段拼错、路径非法、license 非 SPDX，它都照单全收。
- 例如
"requrie"（少个i）写成顶层字段，install不报错，只是默默忽略整个 require 区块 → 导致依赖没装上却无提示 -
"autoload": {"psr-4": {"App\": "src//"}}（末尾双斜杠），install不检查，直到运行composer dump-autoload或实际加载类时才爆Invalid PSR-4 mapping -
"type": "libary"（拼错）或"minimum-stability": "dev-master"（已弃用），install也不拦，只在后续求解依赖时可能因逻辑冲突间接暴露
真正触发架构校验的只有 composer validate
composer validate 是唯一调用 Composer 官方 JSON Schema 并执行字段级语义检查的命令。默认模式下它仍很宽松，但加 --strict 后才会把拼写错误、弃用值、非标准 license 等全部变成硬性错误：
-
"name": "myapp"（缺 vendor 前缀）→--strict直接失败，退出码 1 -
"config": {"allow-plugins": true}（老版本不识别）→--strict拦截，避免 CI 中因 Composer 版本差异导致行为不一致 -
"license": "MIT License"（非 SPDX）→ 默认仅警告，--strict升级为错误
注意：validate 从不联网、不查 Packagist、不解析版本约束，它只认字符串格式和 schema 规则。
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
install --dry-run 才暴露依赖层问题，不是架构校验
composer install --dry-run 看似“校验”，实则是模拟安装全流程：解析 composer.json 和 composer.lock、联网查包、求解依赖图、验证平台约束（PHP 版本、扩展）、检查 autoload 路径是否可达 —— 这些都不是架构校验，而是逻辑可行性验证。
- 它能发现
"monolog/monolog": "999.0.0"这种版本根本不存在，但前提是它先成功解析了 JSON - 它会报
Could not find package或Version conflict，但这些错误和composer.json是否符合 schema 无关 - 它不关心字段名拼错，只关心“这个字段如果存在，它的值能不能被 resolve”
CI/CD 中必须拆开两步：validate + dry-run
靠 install 或 install --dry-run 单独跑，永远无法提前捕获架构低级错误。生产 CI 必须显式组合：
-
composer validate --strict --no-check-publish：确保语法、字段、结构无硬伤 -
composer install --dry-run --no-interaction：确认依赖可解、包存在、锁文件一致
漏掉前者，install --dry-run 可能因 JSON 解析失败而中断，但错误信息远不如 validate 明确；漏掉后者，validate 通过后仍可能在部署阶段因依赖不可达而崩溃。两者职责完全不同，不可互相替代。
