最可靠的方式是抓真实请求：用curl -v模拟Composer UA和Accept头直连镜像地址，观察输出是否含“Connected to mirrors.aliyun.com”，而非仅依赖composer config配置；浏览器访问易因UA被拒导致误判。
如何确认 Composer 正在用镜像，而不是官方源
配置了 composer config -g repos.packagist.org 并不等于请求真发到了镜像站——DNS 污染、/etc/hosts 冲突、代理拦截都可能导致“配置生效但流量绕行”。最可靠的方式是抓一次真实请求：
- 用
curl -v -H"User-Agent: Composer/2.9.6" -H"Accept: application/json" https://mirrors.aliyun.com/composer/packages.json 2>&1 | grep "Connected to\|HTTP/"，看到Connected to mirrors.aliyun.com才算实锤 - 别用浏览器访问
packages.json，多数镜像会根据User-Agent返回 403，误判为“不可用” - 如果输出里出现
Connected to packagist.org或卡在 DNS 解析，说明配置没生效，或被本地~/.composer/config.json里的项目级设置覆盖
监控 Composer 命令是否卡在元数据同步阶段
Composer 安装/更新慢，80% 是卡在 Resolving dependencies 阶段，本质是反复拉取和解析 packages.json 缓存。这个过程无法被 --profile 精确拆解，但可通过外部手段定位：
- 执行
composer update --profile --no-progress 2>&1 | grep "Resolving dependencies"，看该阶段耗时是否超总时间 60% - 检查缓存文件新鲜度：
ls -lh ~/.composer/cache/repo/https---mirrors.aliyun.com-composer/packages.json，若修改时间 > 15 分钟，说明 Composer 在用过期元数据重算依赖 - 强制刷新元数据：
composer update --refresh（仅 Composer ≥ 2.5 支持），它只更新packages.json，不重下 ZIP 包，耗时通常
为什么不能用 Prometheus 直接采集 Composer 运行指标
Composer 是短生命周期 CLI 工具，没有 HTTP server、不暴露 /metrics、也不持久化进程 ID。所谓“监控 Composer”，实际监控的是它的上下文环境：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
process_exporter只能告诉你“某时刻有个 composer 进程存在”，无法关联 PHP 版本、项目路径、镜像源 URL 等关键维度 - 真正可打点的指标在外部：镜像源的
probe_http_duration_seconds{url="https://mirrors.tencentyun.com/composer/p2/monolog/monolog.json"}、本地磁盘node_filesystem_avail_bytes{mount="/home"}、PHP 内存峰值（在自定义post-install-cmd脚本中调用memory_get_peak_usage()） - 如果非要上报，建议把
composer install --profile输出解析成结构化日志，写入/var/log/composer-profile.log，再由 Filebeat 推送到 ELK
PHPStorm 里看不到镜像状态，不是 Bug 是设计
PHPStorm 的 Settings → PHP → Composer 页面只管调用哪个 composer 可执行文件，它完全不读取也不渲染镜像配置。所有“可视化”都得靠间接验证：
- 在 PHPStorm 终端运行
composer config -g repos.packagist.org，确认输出是预期镜像地址 - 执行
composer require monolog/monolog -vvv，观察日志里下载 ZIP 的 URL 是否含mirrors.aliyun.com，这是唯一可信依据 - 别信 “Package installed successfully” 提示——它不校验来源；必须看到
Downloading https://mirrors.../dist/monolog/monolog/...这一行才算落地
复杂点不在工具链，而在判定逻辑：同一个 503 错误，可能是镜像站限流、DNS 污染、本地代理故障，还是 composer.json 里写了已下线的私有包——你得先分清是网络层、配置层，还是业务层的问题。
