应监控php cli进程实际内存峰值，而非composer自身；可用php -d memory_limit=2g composer install 2>&1 | grep "peak memory"（composer 2.9.6+）或ps aux --sort=-%mem | head -5抓取高内存php进程，php的memory_limit才是硬门槛。
怎么确认 Composer 进程真实内存峰值
别信 composer --profile，它只报时间不报内存；Allowed memory size exhausted 错误也不是 Composer 自己抛的，而是 PHP 进程在解析 composer.lock 或构建依赖图时被内核 kill。真要看内存，得盯 PHP CLI 进程本身。
Linux/macOS 下最直接：php -d memory_limit=2G composer install 2>&1 | grep "Peak memory"（Composer 2.9.6+ 自带该日志）；CI 中用 ps aux --sort=-%mem | head -5 抓住那个吃内存最多的 php 进程——不是 composer 命令名，是底层的 php 进程。
-
COMPOSER_MEMORY_LIMIT完全不控制这个峰值，它只影响 Composer 内部某些可中断逻辑（比如回溯步数），PHP 底层的memory_limit才是硬门槛 - 如果
php -r "echo ini_get('memory_limit');"输出还是128M，说明你写的-d没生效，大概率是用了 shell wrapper（如 Ubuntu 的/usr/bin/composer） - 验证是否真走分片镜像：加
-v后看日志里是不是出现多个packages-a.json、packages-l.json等请求，而不是只有一行Loading https://mirrors.aliyun.com/composer/packages.json
压测命令必须带哪些参数才有效
随便跑 composer install 测不出真实瓶颈，干扰项太多。要测出“纯解析+autoload 注册”阶段的内存压力，就得剥离网络、缓存和 dev 包这些变量。
标准压测命令长这样：time rm -rf vendor composer.lock && composer clear-cache && php -d memory_limit=2G COMPOSER_MEMORY_LIMIT=1536M composer install --no-dev --optimize-autoloader --classmap-authoritative -v
-
--no-dev跳过所有require-dev包元数据加载，内存常降 40%~60% -
--optimize-autoloader和--classmap-authoritative必须一起用，否则 PSR-4 映射仍会动态扫描路径，dump 阶段照常爆内存 -
-v是关键，没它看不到分片加载日志，也看不到Peak memory行 - Windows PowerShell 用户注意：
php -d "memory_limit=2G"引号不能少，否则-1或2G被 shell 截断
为什么阿里云/腾讯云镜像能降低内存，但华为云不行
不是所有中文镜像都一样。卡在 Loading composer repositories 阶段，本质是 Composer 默认把整个 Packagist 索引（几 MB JSON，解析后膨胀成几百 MB 数组）全拉进内存。只有支持索引分片的服务端才能缓解——目前仅阿里云、腾讯云镜像明确实现了 packages-a.json、packages-z.json 这类按首字母切分的子文件。
- 验证配置是否生效：运行
composer config -g repos.packagist.org.url，输出必须是https://mirrors.aliyun.com/composer/或https://mirrors.cloud.tencent.com/composer/，含packagist.org就是 fallback 到官方源了 - 项目级
composer.json里定义了repositories？它会覆盖全局配置，且若 URL 没指向分片镜像，照样全量加载 -
--prefer-dist对内存无影响，它只改包本体下载方式（zip vs git），不干预元数据加载路径 - 旧版 Composer（如 2.2.x）不识别分片结构，会退化为全量下载，必须升到 2.9.6+
容易被忽略的内存泄漏点
Web 环境下反复 require 'vendor/autoload.php' 是隐形杀手。PHP-FPM 或 Swoole 长生命周期中，每次 require 都新建一个 Composer\Autoload\ClassLoader 实例，每个实例都持有一份完整映射表——不是几百 KB，是几 MB × N 次。
- 运行
var_dump(spl_autoload_functions())，如果看到多个Composer\Autoload\ClassLoader::loadClass（对象 ID 不同），就是重复注册 - 只应在项目唯一入口（如
public/index.php）加载一次 autoload，中间件、路由、CLI 命令里再 require 就是 bug - CI/CD 中
php -d memory_limit=-1有时无效，不是参数错，而是容器内存配额（cgroup limit）比 PHP 设置更低，进程先被 OS kill - Xdebug 必须关掉：
php -d zend_extension= -d xdebug.mode=off composer install，否则解析慢 5–10 倍，内存占用也更难收敛
