composer validate 报错需先定位行号列号，检查末尾逗号、中文标点、单引号、注释等；用 php -r json_decode 快速验证纯语法；--strict 仅强化 schema 校验而非 JSON 解析；validate 通过不保证 install 成功，需 --dry-run 测试依赖语义。
composer validate 报错但看不出哪错了？先盯住行号列号
Composer 不会直接告诉你“少了个逗号”，而是抛出类似 JSON parse error on line 12 at column 5 这种提示——它非常诚实，也足够精准。问题一定就在第 12 行、第 5 列附近，别急着重写整个 composer.json。
- 用编辑器跳转到对应行，重点检查：末尾多出的逗号（尤其在最后一个数组项后）、混入的中文标点（如全角
，或：）、单引号代替双引号、意外粘贴进来的注释（JSON 不支持//或/* */） - 打开编辑器右下角状态栏，确认文件被识别为
JSON with Schema，不是纯文本；否则高亮和校验都会失效 - 如果行号显示异常（比如报错在第 1 行，但文件明显不止一行），大概率是 UTF-8 BOM 头或不可见控制字符作祟，可用
xxd composer.json | head查看开头是否含ef bb bf
json_decode() 比 composer validate 更快定位纯语法错误
composer validate 会同时做 JSON 解析 + Composer schema 校验，一旦 schema 层出错，可能掩盖底层语法问题。想绕过 schema、只测“是不是合法 JSON”，用 PHP 原生解析更直接。
- 运行：
php -r "$j = file_get_contents('composer.json'); $d = json_decode($j); if (!$d) { echo json_last_error_msg().\"\n\"; }" - 输出
null且提示Syntax error，说明 JSON 确实非法；若提示Control character error，基本可锁定换行符或 BOM 问题 - 这个方法不依赖 Composer，也不联网，秒出结果，适合 CI 中快速兜底
--strict 不是“更严格地检查语法”，而是校验字段合规性
composer validate --strict 不会让 JSON 解析更严，它只是把原本当警告处理的 schema 问题（比如缺失 description、license，或把 autoload 拼成 autoloader）升级为错误，强制你修复。
- 典型报错：
Property author is not defined→ 应为复数authors，且值必须是数组 -
"type": "libary"（拼错）→ JSON 能过，但--strict会指出该值不在枚举列表中 - CI 中建议固定使用
composer validate --strict --no-check-publish：前者防低级错误，后者避免因网络或 Packagist 权限导致流程中断
validate 通过 ≠ 项目能装上包
composer validate 是个离线静态检查，它不联网、不查 Packagist、不解析依赖树。所以你会遇到 ./composer.json is valid，紧接着 composer install 就报 Could not find package xxx。
- 真正暴露依赖问题的命令是：
composer install --dry-run --no-interaction或composer update --dry-run - 它们会模拟完整解析流程：检查包名是否存在、版本约束是否可满足、PHP 平台配置是否兼容、
autoload路径是否真实存在 - 很多团队只在 CI 里跑
validate，结果上线前才发现 require 里写了错包名——这不是配置语法问题，是语义落地问题
真正卡住人的，往往不是 JSON 语法错，而是字段语义错（比如 autoload 路径指向不存在的目录）、版本约束错（比如 "monolog/monolog": "2.x" 非标准写法）、或平台配置冲突（php: ^8.0 但本地是 8.3）。这些，validate 一律不管。
