Composer install失败主因是镜像配置错误：键名必须为repo.packagist、type必须显式设为composer、URL需HTTPS且末尾带/；项目级配置优先于全局，全局配置在有项目repositories字段时完全失效；还需检查CA证书、清缓存、验证日志路径。
Composer install 报错，八成不是网络差、不是 PHP 坏，而是镜像根本没配对——漏一个斜杠、少个 composer 类型参数、键名写成 repos.packagist，它就安静退回 https://packagist.org，不报错也不提示。
为什么 composer config -g repo.packagist 看起来成功却没生效
这条命令静默失败的三个硬条件必须同时满足：
-
repo.packagist是唯一合法键名（不能是repos.packagist、repositories.packagist或packagist.org） - 中间必须显式传入
composer作为type值：漏掉它，Composer 2.x 直接忽略该配置 - URL 必须是 HTTPS 且末尾带
/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（拼路径时变成/composerpackages.json，404）
验证是否真写进去了：运行 composer config -g repo.packagist。输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或仍返回 https://packagist.org，说明没写对。
项目级配置比全局更可靠，尤其在宝塔/CI/Docker 中
全局配置写在 ~/.composer/config.json，但只要项目根目录 composer.json 里存在 "repositories" 字段（哪怕只是 "repositories": []），全局设置就完全被跳过——不是优先级低，是彻底失效。
更关键的是权限问题：
- 宝塔默认用
www用户执行命令，你在终端用root配的全局配置，www根本读不到 - CI runner（如 GitHub Actions）或 Docker 容器里可能根本没有
~/.composer目录
推荐做法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加 -g）。它会自动合并到 composer.json 的 repositories 字段中，key 固定为 "packagist"。如果原 composer.json 是 "repositories": []，需先手动改为 "repositories": {} 再执行，否则报错。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer install 卡在 “Loading composer repositories” 或报 SSL 错误
镜像只加速元数据和 ZIP 包拉取，不解决证书链或缓存污染问题。
常见真实原因：
- PHP 的
openssl.cafile和curl.cainfo指向了过期的 CA 证书文件（比如停更于 2021 年的curl-ca-bundle.crt）；修复方式是下载最新cacert.pem（从https://curl.se/ca/cacert.pem），并在php.ini中统一设置两者 -
composer.lock里硬编码了旧 provider 地址，不删它，Composer 就一直重试失败路径 - 缓存残留导致 Composer 拿着旧路径去新源上找不存在的东西：先执行
composer clear-cache；Windows 用户还得手动删%LOCALAPPDATA%\Composer\cache - 手动验证镜像可用性：
curl -I https://mirrors.aliyun.com/composer/packages.json必须返回HTTP/2 200；若返回 HTML 页面（如人机验证），说明该镜像不适合自动化场景
composer install 报 “Your requirements could not be resolved”
这不是依赖冲突，而是本地环境不满足 composer.lock 里已锁定包的运行前提。
常见原因：
- PHP 版本低于锁文件中某包要求的最低版本（比如锁了
monolog/monolog:v3.5.0，但它要求 PHP >=8.1，而你本地是 PHP 8.0） - 扩展缺失：
ext-mbstring、ext-xml、ext-curl等未启用，composer diagnose会直接标出 -
composer.json顶部"config": {"platform": {}}写死了平台版本，但和实际运行环境不符（例如写"php": "8.2.10"，却在 PHP 8.1 下执行）
--ignore-platform-reqs 是临时绕过手段，不是解决方案；加了它装出来的包大概率运行时报错。
最常被忽略的一点：composer install 成功不代表能跑起来。类找不到、命令不存在、php artisan 报错，90% 是因为 autoload 没生效或路径映射错位——别急着重装，先看 vendor/autoload.php 是否可读、vendor/composer/autoload_classmap.php 是否生成、composer dump-autoload 是否执行过。
