composer validate 是唯一能直接校验 composer.json 语法和结构的官方命令，但默认仅做基础 JSON 与 schema 检查；报 JSON parse error 须据行号列号精确定位，常见问题包括末尾逗号、单引号、全角符号、零宽空格；加 --strict 才启用字段合法性、弃用项等完整校验，CI/CD 中应强制使用并配合 --no-check-publish 和 --dry-run。
composer validate 是唯一能直接验证 composer.json 格式与结构合法性的官方命令，但它默认只做轻量级校验 —— 通过不等于能装上，更不等于没逻辑错误。
composer validate 报 JSON parse error 怎么快速定位
这不是 Composer 特有错误，而是纯 JSON 语法崩了，必须按行号列号硬找。错误里写的 line 12 at column 5 就是精确位置，不是示意。
- 最常见元凶：
"require": {"monolog/monolog": "^2.0",}这种末尾多逗号；用单引号代替双引号（'name': 'myorg/myapp'❌）；从网页复制内容带的全角冒号或零宽空格（U+200B） - 终端里快速筛隐藏字符：
cat -A composer.json | head -n 15看有没有^M、M-BM-^或ZWSP类标记 - 绕过 Composer 直接测 JSON：
php -r "$j = file_get_contents('composer.json'); var_dump(json_decode($j));"，失败时会输出json_last_error_msg()，比 validate 的提示更直白
为什么加 --strict 才算真校验
默认模式下，很多低级错误会被当空气放过：字段拼错、弃用写法、非标准 license 值，都只警告不报错 —— CI/CD 里这等于放行缺陷。
-
"autoloader"拼成"autoloader"？默认不报；加--strict直接失败 -
"license": "MIT License"（非 SPDX 标准）？默认警告；加--strict变错误 -
"type": "libary"（拼错）或"minimum-stability": "dev-master"（已弃用）？只有--strict才拦截 - CI 脚本推荐固定用：
composer validate --strict --no-check-publish，跳过 Packagist 发布检查，避免网络中断流程
validate 通过了，install 却失败？正常
validate 不联网、不解析依赖、不查 PHP 版本兼容性，它只管“写得对不对”，不管“说的包存不存在”或“当前环境能不能跑”。
-
"require": {"php": ">=8.0"}在 PHP 7.4 环境下照样通过 validate，但install会立刻挂 -
"monolog/monolog": "2.x"这种非法版本约束，validate 不报，install才提示Could not parse version constraint - 私有包名
"myorg/mylib"没配repositories？validate 完全沉默，直到install阶段才报Could not find package - 真正暴露依赖问题，得靠
composer install --dry-run或composer update --dry-run
composer validate --lock 是干啥的
它不校验 composer.lock 文件本身语法，而是检查 lock 文件是否由当前 composer.json 生成 —— 防止手动改 lock 导致依赖关系脱节。
- 如果你改过
composer.lock（比如删掉某行 hash），composer validate --lock会直接报错 - 它和
--strict可共存：composer validate --lock --strict，但二者目标不同：前者保一致性，后者保完整性 - 注意：
composer validate默认不读composer.lock，不加--lock就完全不碰它
最容易被忽略的一点：validate 不检查 autoload 中路径是否存在、类名是否冲突，也不校验 scripts 里命令能否执行 —— 它只校验“配置写得像不像人话”，不是“配置跑不跑得通”。真要兜底，--dry-run 比 validate 更接近真实安装过程。
