Composer安装慢的根源是默认直连packagist.org导致DNS/TLS/CDN层层受阻，且仅配置镜像地址不解决元数据请求仍回源的问题；必须用repos.packagist配置镜像并禁用HTTPS校验，同时注意同步延迟与签名策略差异。
Composer 安装慢、依赖解析卡住、composer install 半小时没反应——根本不是你网络差，而是默认走的 Packagist.org 全球源在 DNS 解析、TLS 握手、CDN 跳转上层层受阻。国内全量镜像确实能提速，但「全量」不等于「开箱即用」，镜像同步延迟、元数据不一致、HTTPS 证书校验失败才是真瓶颈。
为什么 composer config -g repo.packagist 设置镜像后仍慢？
单纯改 repo.packagist 只影响包下载，不影响依赖解析阶段的 packages.json 元数据请求——这部分仍直连 packagist.org。国内镜像（如腾讯、阿里、华为）虽提供 packages.json，但它们并非实时同步，且 Composer 默认不信任非官方源的元数据签名。
实操建议：
- 必须同时配置
packagist.org的镜像地址和禁用其 TLS 验证（否则会因证书链不匹配失败） - 使用
composer config -g repos.packagist composer https://mirrors.tencent.com/composer/（注意是repos.packagist，不是repo.packagist） - 加上
--no-plugins参数首次运行，避免某些插件强行回源 - 若项目含私有包或
path类型仓库，镜像配置不能覆盖它们，需单独保留原定义
composer update 卡在 Resolving dependencies 怎么破？
这不是网络问题，是 Composer 5.x+ 默认启用的「SAT solver」在本地穷举版本组合。国内镜像虽快，但若 composer.lock 里记录的是旧版约束，而镜像元数据滞后，Solver 就会反复尝试已下线的版本号，陷入死循环。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 先删掉
composer.lock（仅限开发环境），再跑composer update --with-all-dependencies - 加
-v参数看具体卡在哪条包的versions请求，确认该包是否在镜像中存在（直接 curlhttps://mirrors.tencent.com/composer/p2/vimeo/vimeo-api.json测试） - 临时降级 Solver：设环境变量
COMPOSER_DISABLE_AUTOLOAD=1并加--prefer-stable --no-suggest减少候选集
镜像源选腾讯、阿里还是华为？关键看同步延迟和 HTTPS 支持
三者都不是实时同步，但策略不同：腾讯镜像每 5 分钟拉一次，但会跳过签名验证；阿里镜像每 30 分钟同步，强制校验 packages.json 签名，若签名失效就返回 404；华为镜像无签名校验，但部分区域 CDN 节点缺失导致偶发 502。
实操建议：
- 生产环境优先用腾讯源：
composer config -g repos.packagist composer https://mirrors.tencent.com/composer/ - 若遇到
file could not be downloaded: SSL operation failed，立即补上composer config -g secure-http false（仅对镜像域名生效，不影响其他 HTTPS 请求） - CI/CD 中不要依赖全局配置，应在
composer.json顶层写"repositories": [{"type": "composer", "url": "https://mirrors.tencent.com/composer/"}]，避免环境污染
最麻烦的不是配错地址，而是以为配完就一劳永逸——镜像状态得定期 check，比如每月用 composer show monolog/monolog | grep versions 对比官网显示的最新版是否一致；一旦发现滞后超 24 小时，就得切源或临时回退到 packagist.org + curl -x 指定代理。
