报错“Connection refused”或“cURL error 7”是网络连通性问题而非Composer配置错误：需先检查DNS（ping packagist.org）、TCP连接与TLS握手（curl -v），再验证镜像是否正确写入全局配置。
报“Connection refused”或“cURL error 7”：先别动composer config
这不是 Composer 配置错了，是系统根本没连出去。DNS 解析失败、防火墙拦截、代理静默丢包，都会卡在这一步。
- 运行
ping packagist.org—— 如果返回unknown host，说明 DNS 不通，立刻改/etc/resolv.conf（Linux/macOS）或网络适配器设置（Windows），加一行nameserver 8.8.8.8 - 运行
curl -v https://mirrors.aliyun.com/composer/—— 卡在* Connected to是 TCP 层不通；卡在* TLS handshake是证书或 SNI 问题，可临时加CURL_IPRESOLVE=4强制走 IPv4 -
composer config -g repo.packagist输出仍是https://packagist.org？说明镜像根本没写进去，不是“没生效”，是命令写错了（漏composertype、缺末尾/、键名写成repos.packagist）
报“Permission denied”写 vendor/ 或 composer.lock：别急着 chmod
90% 的权限报错不是权限不够，而是目录归属错了——vendor/ 或 composer.lock 被 sudo composer install 污染过，现在属主是 root，而你用普通用户再跑就拒绝写入。
- 看报错路径：
file_put_contents(/path/to/vendor/autoload.php): Permission denied→ 直接执行ls -ld vendor/，如果显示root root，就确认是归属问题 - 修复命令是
sudo chown -R $USER:$USER vendor/ composer.lock（Linux/macOS）或右键属性 → 安全 → 编辑当前用户权限（Windows） - 别用
chmod 777—— 这会让 Composer 后续拒绝写入，它会检查目录权限是否过于宽松
报“Your requirements could not be resolved”：不是依赖冲突
这是 composer install 在严格还原 composer.lock，但你的 PHP 环境不满足锁文件里某包的硬性要求。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer diagnose，重点看PHP version和Extensions行 —— 缺ext-mbstring、ext-xml或 PHP 版本低于锁文件中某个包声明的最低版本（比如monolog/monolog v3.5.0要求PHP >= 8.1，而你是 8.0） - 检查
composer.json顶部是否有"config": {"platform": {"php": "8.2.10"}}—— 如果实际 PHP 是 8.1，它就会假装自己是 8.2.10，导致装完后运行时报错 -
--ignore-platform-reqs只能临时绕过，装出来的包大概率在php artisan或自动加载时崩，不是解法
换镜像后仍卡在 “Loading composer repositories”：缓存和 lock 文件在捣鬼
镜像配置正确 ≠ 立刻生效。Composer 会优先读缓存里的元数据，而 composer.lock 里硬编码了旧源地址，不清理就一直重试失败路径。
- 必须执行
composer clear-cache；Windows 用户还要手动删%LOCALAPPDATA%\Composer\cache - 删掉
vendor/和composer.lock—— 尤其是composer.lock，它记录的是上次成功安装时的 provider URL，换源后不删它，Composer 就拿旧地址去新镜像站找包，必然 404 - 验证真实请求地址：运行
composer install -vvv 2>&1 | head -n 10 | grep Downloading，第一行的 URL 才是你当前真正访问的源，不是composer config输出的那个
真实环境里最容易被跳过的，是 composer.lock 文件本身的存在性检查 —— 它不存在时，composer install 会退化成 update，结果不可控；还有就是项目级 repositories 字段，哪怕只是空数组 []，也会让全局镜像彻底失效。
