错误根源是DNS、TLS或镜像URL问题，需依次验证curl连通性、镜像配置正确性、项目级repositories干扰、代理设置及hosts映射，并清缓存、查依赖冲突、避杀软拦截。
“Could not fetch packages.json” 或卡在 “Loading composer repositories”
这根本不是 vendor 目录或 PHP 环境的问题，而是 Composer 根本没拿到包元数据——它连镜像服务器的 packages.json 都拉不下来。错误源头只在 DNS、TLS、镜像 URL 三者之一。
立刻验证：运行 curl -I https://mirrors.aliyun.com/composer/packages.json。返回 HTTP/2 200 才算通；若报 SSL connect error，说明系统 CA 证书过期，需更新 openssl.cafile 和 curl.cainfo 指向最新 cacert.pem。
- 检查镜像配置是否写对：
composer config -g repo.packagist输出必须是完整 JSON，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；漏掉末尾斜杠、写错键名（比如写成repos.packagist）、少"type"字段，都会静默失效 - 项目级
composer.json里只要存在"repositories"字段（哪怕空数组），全局镜像就完全不生效；此时必须进项目目录执行composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 公司内网或校园网环境下，可临时配代理：
composer config -g http-proxy http://proxy.example.com:8080；用完务必清除：composer config -g --unset http-proxy
“file could not be downloaded” 或超时卡死
国内直连 packagist.org 基本不可靠，这不是你本地网络差，而是整条链路（DNS 解析 → TLS 握手 → TCP 连接 → CDN 回源）中任意一环都可能断。
最有效动作只有两步：切镜像 + 清缓存。别跳过第二步——旧失败记录留在缓存里，重试照样失败。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 切阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 强制清缓存：
composer clear-cache - 仍不行？手动改
/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows），加一行：137.74.169.73 packagist.org（IP 以实时查询为准）
“Your requirements could not be resolved” 却提示连接失败
这个错误本身和网络无关，但新手常因反复重试 composer update 导致大量失败请求打到镜像服务器，触发限流或临时封禁，进而出现假性“连接失败”。此时看到的报错是表象，根源是依赖冲突已存在，只是被网络层掩盖了。
先停掉所有重试，回到本质：运行 composer why-not php:8.3（把 8.3 换成你目标版本），直接看哪个包在拦路；再跑 composer prohibits guzzlehttp/guzzle 查谁锁死了旧版 Guzzle。
- 别删
vendor/和composer.lock再重装——这解决不了约束打架，反而让问题更难复现 - 确认 PHP CLI 版本真实可用：
php -v和php -m | grep -E "mbstring|openssl|curl|json"，Web 环境和 CLI 可能加载不同php.ini -
composer install --ignore-platform-reqs是临时绕过手段，上线前必须让代码真兼容目标环境
Windows 下 Access is denied 且错误出现在生成 .bat 文件时
这不是权限不足，而是杀软（尤其是 Windows Defender 实时防护）拦截了 Composer 自动创建批处理脚本的过程。
- 临时禁用 Windows Defender 实时防护，再运行
composer install - 或改用 Git Bash 执行命令——它不走 Windows 的 CMD/PowerShell 路径，避开了杀软对 .bat 的敏感监控
- 切勿用
sudo或管理员身份运行 Composer，这会导致vendor/属主变成root，后续普通用户操作全报 Permission denied
真正卡住的地方往往不是“连不上”，而是“连上了却拿不到正确响应”——比如镜像 URL 少个斜杠、CA 证书过期、hosts 文件映射失效、或者误配了仅对内部服务有效的代理。每一步验证都要有明确预期结果，而不是盲目重试。
