不是。这一阶段根本没开始加载任何包元数据，更不涉及反序列化——它卡在 dns 解析、tls 握手或 packagist.org/mirrors 的 packages.json 下载失败上。
composer install 卡在 “Resolving dependencies” 是内存问题吗？
不是。这一阶段根本没开始加载任何包元数据，更不涉及反序列化——它卡在 DNS 解析、TLS 握手或 packagist.org/mirrors 的 packages.json 下载失败上。所谓“Metadata 反序列化逃逸”，压根还没发生。
真正触发元数据解析和反序列化的环节是：Downloading https://mirrors.aliyun.com/composer/p2/laravel/framework.json 之后，Composer 把下载到的 JSON 文件解码为 PHP 数组，再写入本地缓存（~/.composer/cache/repo/https---mirrors-aliyun-com-composer/p2/）。这个过程才可能因畸形 JSON 或超大嵌套结构引发内存暴涨。
- 用
composer install -vvv 2>&1 | grep "Downloading.*.json"确认是否真走到这步 - 若卡在
Downloading后无日志，立刻检查磁盘空间（df -h ~/.composer/cache）和文件句柄（lsof -u $USER | wc -l），而非怀疑反序列化 - 真实反序列化卡顿通常伴随
PHP Fatal error: Allowed memory size of XXX bytes exhausted，且堆栈里含json_decode或ComposerUtilJsonFile::parse
如何验证是不是镜像源返回了异常 metadata？
别信 composer config -g repo.packagist 输出，直接抓包看实际响应内容。阿里云等镜像站若同步滞后或中间 CDN 缓存污染，可能返回截断、乱码或非标准 JSON 的 xxx.json 文件，导致 json_decode() 失败后反复重试、内存持续增长。
- 手动请求一个典型包元数据：
curl -sSL "https://mirrors.aliyun.com/composer/p2/laravel/framework.json" | head -n 20，确认开头是{"packages":{而非 HTML 或 404 页面 - 检查 HTTP 响应头：
curl -I "https://mirrors.aliyun.com/composer/p2/laravel/framework.json"，确保Content-Type: application/json且状态码为 200 - 若返回内容明显异常（如含
），说明镜像站未正确代理 JSON 请求，需临时切回官方源：<code>composer config --global repo.packagist.org composer https://packagist.org
metadata 反序列化内存占用高，怎么定位具体包？
Composer 不会把所有 p2/*.json 一次性全读进内存，而是按需加载。但某些包（尤其是历史版本多、分支杂、require 太深的）其 framework.json 可达 10MB+，json_decode($json, true) 后数组内存占用常翻 3–5 倍。这不是逃逸，是 PHP 数组结构本身的开销。
- 启用内存分析：
COMPOSER_MEMORY_LIMIT=-1 composer install -vvv --profile 2>&1 | grep -A5 "Scanning p2"，找耗时最长的p2/xxx.json - 单独测试可疑包：
php -r '$j=file_get_contents("https://mirrors.aliyun.com/composer/p2/laravel/framework.json"); echo memory_get_usage(true), "\n"; json_decode($j, true); echo memory_get_usage(true), "\n";' - 若单个 JSON 就吃掉 200MB+，说明该包 metadata 设计失控，可向 Packagist 提 issue，或临时在
composer.json中用"laravel/framework": "10.0.*"锁窄版本范围，避开臃肿的历史元数据
--no-cache 能绕过 metadata 反序列化问题吗？
不能。--no-cache 只跳过本地缓存读取和 HTTP 缓存头（ETag/Last-Modified），但下载下来的 JSON 文件仍要被 json_decode()，该步骤无法跳过。反而因每次都重新下载，更容易暴露镜像源返回异常内容的问题。
- 真正有效的缓解手段是：先
rm -rf ~/.composer/cache/repo/https---mirrors-aliyun-com-composer/p2/清空已损坏的缓存，再加--no-cache强制重拉 - 若问题复现，说明镜像源本身不稳定；此时应换源（如腾讯云
https://mirrors.cloud.tencent.com/composer/）或降级为composer install --no-plugins --no-scripts暂避插件触发的额外元数据解析 - 永远不要在 CI 中只依赖
--no-cache来“解决”内存问题——它掩盖了镜像配置错误或项目依赖失控的真实病因
真正难排查的，是那些没报错、不崩溃、但每次 composer install 都比上次多占 20MB 内存的 case。这种缓慢累积往往源于 autoload 配置错误导致 Composer 反复扫描 vendor 目录生成 classmap，和 metadata 反序列化无关——但日志里都显示为“慢”，容易误判。
