Composer报UnexpectedValueException主因是JSON解析失败，源于composer.json/composer.lock格式错误、远程源返回非法JSON或PHP JSON扩展异常。
Composer 报 UnexpectedValueException 通常是因为 JSON 解析失败
这个异常不是 Composer 自身逻辑错误，而是它在读取 composer.json、composer.lock 或远程仓库返回的元数据（如 packages.json）时，遇到非法 JSON 格式——比如末尾多逗号、单引号代替双引号、Unicode 转义不完整、BOM 头干扰等。根本原因在于 PHP 的 json_decode() 返回 null，Composer 检测到后抛出该异常。
检查本地 composer.json 和 composer.lock 的 JSON 合法性
90% 的本地报错源于这两个文件。别只靠肉眼扫，用工具验证：
- 运行
php -l composer.json只能检查 PHP 语法，不能验证 JSON；正确命令是：php -r "json_decode(file_get_contents('composer.json')); echo json_last_error_msg();"输出JSON_ERROR_NONE才算合法 - 常见低级错误：最后一行字段后多写逗号（
"require": { "php": "^8.1", }）、用中文引号或全角字符、Windows 记事本保存带 BOM 的 UTF-8 文件 -
composer.lock不要手动编辑。如果怀疑损坏，可删掉它再运行composer install重建（前提是composer.json没问题）
远程源返回损坏 JSON 导致的 UnexpectedValueException
这类问题表现为执行 composer update 或 composer require 时突然报错，且错误堆栈指向 Repository/ComposerRepository.php。本质是 Packagist 或私有源返回了格式错误的 JSON 响应（例如 CDN 缓存污染、代理截断响应、HTTPS 中间件注入 HTML 错误页）。
- 先复现并定位源：
composer config --list | grep repos查看当前配置的仓库；用curl -v https://packagist.org/packages/list.json?vendor=monolog直接请求对应 URL，检查响应体是否为纯 JSON - 若响应里混有 HTML（如
...502 Bad Gateway），说明网络链路某处（公司代理、DNS 污染、hosts 劫持）把 JSON 接口当网页处理了 - 临时绕过：改用国内镜像源，如
composer config repo.packagist composer https://packagist.phpcomposer.com（注意该地址已停用，推荐https://mirrors.aliyun.com/composer/） - 终极排查：加
-vvv参数运行命令，Composer 会打印实际请求的 URL 和响应头，确认是否收到 200 +application/json
PHP 版本与 JSON 扩展兼容性问题
极少数情况出现在老旧环境：PHP 7.2 以下版本对某些 Unicode 字符（如 emoji、生僻汉字）解析不稳定；或系统禁用了 json 扩展（虽罕见，但 php -m | grep json 应输出 json）。
- 检查扩展是否启用：
php -m | grep json
若无输出，需在php.ini中取消;extension=json的注释（PHP 7.4+ 默认内置） - 升级 PHP 是最稳妥方案。PHP 7.2 已 EOL，Composer 2.2+ 明确要求 PHP >=7.2.5；若无法升级，至少确保使用 Composer 2.1.x 分支
- 不要试图用
iconv()或正则清洗 JSON 字符串——这会破坏结构。JSON 必须由生成端修复
真正麻烦的是错误发生在私有 Satis / Private Packagist 服务返回的元数据里，而你没有权限登录服务器查日志。这时候得靠 -vvv 输出的请求 URL + 手动 curl 抓包，一帧一帧比对响应内容。
