composer validate 是唯一能直接校验 composer.json 语法和结构的官方命令，但默认仅做轻量级 JSON 与 schema 检查；报 JSON parse error on line 12 at column 5 即为精确位置，需用 php -r "json_decode(...)" 或 jq 快速定位非法字符，加 --strict 才启用字段合法性、弃用项等完整语义校验，CI/CD 中应固定使用 composer validate --strict --no-check-publish。
composer validate 是唯一能直接校验 composer.json 语法和结构的官方命令，但它默认只做轻量检查 —— 通过不等于能装上，更不等于没逻辑错误。
报 JSON parse error 怎么快速定位到具体字符
这不是模糊提示，JSON parse error on line 12 at column 5 就是精确位置。问题一定就在那一列附近，别从头重读文件。
- 用
php -r "json_decode(file_get_contents('composer.json')) or die('JSON error: '.json_last_error_msg());"—— PHP 原生解析器报错更准，且位置更可靠 - 用
jq '.' composer.json（需安装jq）：报错直接标出行列；无输出即基本过关 - 打开文件后开启编辑器「显示不可见字符」：重点查末尾逗号、单引号、中文引号、全角冒号、零宽空格（U+200B）、UTF-8 BOM 头（
xxd composer.json | head查ef bb bf） - 别信 IDE 的“自动修复”：它可能把
// comment美化成合法 JSON，但 JSON 标准根本不支持注释
为什么加 --strict 才算真校验
--strict 不是“更严一点”，而是启用完整 JSON Schema 校验 + 额外语义检查。默认模式下很多低级错误会被当空气放过。
- 拼错字段名：
"requrie"（少个 i）默认不报；加--strict直接失败 - license 值非 SPDX 标准：
"license": "MIT License"默认警告；加--strict变错误 - name 缺 vendor 前缀：
"name": "myapp"默认不拦；--strict拒绝 - autoload 路径末尾双斜杠：
"src//"默认不查；--strict报错 - CI/CD 中应固定使用：
composer validate --strict --no-check-publish，跳过 Packagist 发布检查，避免网络中断流程
validate 通过了，install 却失败？这完全正常
composer validate 完全不联网、不查 Packagist、不解析版本约束语义、不验证 autoload 路径是否存在 —— 它只管“写得对不对”，不管“说的包存不存在”或“当前环境能不能跑”。
-
"require": {"nonexistent/package": "dev-main"}：validate 默默放行，install 才报Could not find package -
"php": ">=8.3"写得再规范，PHP 8.2 环境下composer install仍会失败 -
"monolog/monolog": "999.0.0"在 validate 阶段完全合法，install 时才发现这版本根本不存在 - 真正暴露依赖问题的命令是：
composer install --dry-run（Composer 2.5+ 稳定支持），它走完整依赖求解流程，但不写vendor、不改缓存 - CI 中建议组合：
composer validate --strict --no-check-publish && composer install --dry-run --no-interaction
怎么验证 composer.lock 是否匹配当前 composer.json
composer validate --lock 不是“顺便看看”，而是比对 composer.json 的 hash 与 composer.lock 中记录的 hash 是否一致 —— 防止你手动改了 composer.json 却忘了 composer update。
- 它不校验 lock 是否“最新”，只校验“是否由当前 json 生成”
- 如果
composer.lock损坏（比如 Git 合并冲突残留<<<<< HEAD），jq empty composer.lock会直接报错并指明行列 - 损坏时别修，直接删掉
composer.lock，再跑composer install重生成；或执行composer update --lock安全重建 -
composer.lock文件一旦 JSON 格式出错，composer install就会直接失败，且错误信息往往不指明具体哪一行 —— 这时候必须用jq或python3 -m json.tool定位
最常被忽略的是：validate 和 install 是两套逻辑。前者是 lint 工具，后者才是执行预检。在 CI 流水线里，只跑 composer validate 就合入代码，等于把依赖风险留给部署现场。
