“Connection refused”或“cURL error 7”说明请求未发出，需先验证DNS与连通性（如ping、curl测试），再正确配置镜像源（repo.packagist、type composer、URL末尾带/）、清缓存并排除代理及防火墙干扰。
报错里带“Connection refused”或“cURL error 7”
这说明请求根本没发出去，不是 Composer 配错了，是系统连不上网。DNS 解析失败、代理拦截、防火墙挡路，都可能触发这类错误。
先运行 ping packagist.org：如果返回 unknown host，就是 DNS 问题，立刻换 DNS（比如设成 8.8.8.8）；如果能 ping 通，再跑 curl -I https://mirrors.aliyun.com/composer/packages.json 看是否返回 HTTP/2 200。
- 输出
curl: (35) SSL connect error→ TLS 层异常，检查 PHP 的openssl.cafile和curl.cainfo是否指向过期 CA 文件 - 卡在
* Connected to→ TCP 连接失败，可能是企业 HTTPS 解密代理干扰，临时加COMPOSER_DISABLE_TLS=1测试（仅调试） - 返回 HTML 页面（比如人机验证页）→ 镜像源不适合自动化，换阿里云或腾讯云源
报错里有“Permission denied”写 vendor/ 或 composer.lock
这不是权限不够，而是目录“认错了主人”。最常见的是用 sudo composer install 污染了 vendor/ 或 composer.lock，导致当前用户无权修改。
运行 ls -ld vendor/ composer.lock 查归属：如果 owner 是 root，而你当前是普通用户，就必然失败。
- 修复方式是改归属：
sudo chown -R $USER:$USER vendor/ composer.lock - 别用
chmod 777硬开权限——治标不治本，还埋安全隐患 - 宝塔或 CI 环境要注意：你在终端用
root配的全局镜像，但实际执行的是www用户，得用sudo -u www composer config -g单独配
报错是“Your requirements could not be resolved”
这不是依赖冲突，是你本地环境不满足 composer.lock 里锁定的包要求。Composer install 是精确还原，不是智能选版本。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
运行 composer diagnose 会直接标出问题：PHP 版本太低、缺 ext-mbstring、ext-xml 等扩展，或者 composer.json 里写了 "platform": {"php": "8.2.10"} 但你实际跑的是 PHP 8.1。
- 不要加
--ignore-platform-reqs强行过——装完大概率运行时报错 - 确认
composer.lock文件存在且已提交到 Git；不存在时install会 fallback 成update，结果不可控 - 检查
vendor/autoload.php是否真生成了——成功 install 不代表能跑起来，autoload 映射错位才是常见真因
镜像配置看起来生效，但 install 还是走官方源
composer config -g repo.packagist 输出为空或仍是 https://packagist.org，说明配置根本没写进去，不是“没生效”，是压根没存成功。
必须同时满足三个硬条件：repo.packagist（单数、不能是 repos.packagist）、末尾带 / 的 HTTPS URL、命令里显式传 composer 作为 type 值。
- 正确写法：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 项目根目录
composer.json里只要存在"repositories"字段（哪怕只是空数组[]），全局镜像就完全失效 - 验证真实请求地址：运行
composer install -vvv 2>&1 | head -n 10 | grep Downloading，第一行 URL 才是实际走的源
真正卡住的地方往往不在报错文字表面——比如 file_put_contents(): Only variables should be passed by reference 看似 PHP 语法错误，其实是镜像返回了 BOM 头或乱码；比如 Could not fetch packages.json 看似网络问题，实则是缓存里还存着旧路径去新源上找不存在的东西。清缓存、删 vendor/ 和 composer.lock、手动验证镜像可用性，这三步漏一不可。
