快速定位 composer.json 语法错误的唯一准确定位方式是用 PHP 直接解析：php -r "$j=file_get_contents('composer.json');$d=json_decode($j);if(!$d)echo'JSON error:'.json_last_error_msg()." ";"，常见错误包括中文引号、全角冒号、BOM头、末尾多逗号、零宽空格。
怎么快速定位 composer.json 语法错误
JSON 语法错一个字符，composer install 就会静默失败或报奇怪的网络错误，根本不会提示“你 JSON 写错了”。唯一准确定位方式是绕过 Composer，直接用 PHP 解析：
- 执行
php -r "$j = file_get_contents('composer.json'); $d = json_decode($j); if (!$d) { echo 'JSON error: ' . json_last_error_msg() . "\n"; }" - 错误类型常见有：中文引号、全角冒号、BOM 头（VS Code 右下角必须显示 “UTF-8”，不是 “UTF-8 with BOM”）、末尾多逗号、零宽空格（U+200B）
-
composer validate不检查config.json，它只读composer.json；而config.json出错时，Composer 会降级或报Could not find package这类误导性错误
为什么 --strict 是语义校验的生死线
不加 --strict 的 composer validate 基本没用——它把拼错的 "autoloader":{}、废弃的 "minimum-stability": "dev-master"、缺失的 "description" 全当警告放过，且 exit code 仍是 0。CI 流水线里等于白跑。
- 必须用
composer validate --strict --no-check-publish -
--no-check-publish关键在跳过 Packagist 网络请求，避免 DNS 或防火墙导致校验中断 - 报错信息里写的
line 12 at column 5就是真实出错点，别重读整个文件
vendor 文件哈希校验要开实验开关
默认 composer install 只校验 dist 包哈希，但不主动报错；想让它严格拦截篡改或损坏，得启用实验模式：
- 运行
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict - 它会遍历
vendor/下所有包，比对composer.lock中记录的dist.sha256和实际文件哈希 - 注意：该命令不检查 autoload 字段变更，只校验文件内容完整性；若镜像源删了
autoload字段，verify-checksums不会发现，但后续dump-autoload会崩
私有源元数据缺失常被当成“包不存在”
报 Could not find package myorg/utils，90% 不是包真没了，而是你的私有仓库 packages.json 里压根没导出 require 字段，或者根本没同步该包版本。
- 手动验证：用
curl -s https://pkg.myorg.com/packagist/myorg/utils.json | jq '.require'，输出null或空对象就说明元数据不全 - Satis 用户需确认
satis.json启用了"providers": ["*"]和"require-dependencies": true - vcs 类型源必须打 Git tag 或在
composer.json里写死"version": "1.0.0"，否则 Composer 不认为它是可安装版本
真正难排查的不是报错本身，而是 Composer 把三类校验混在同一个流程里：JSON 解析、字段语义、文件哈希。它们触发条件不同、错误表现相似、修复手段完全隔离——不分开验证，永远在兜圈子。
