报错本质是本地CLI环境不匹配：PHP版本低于require声明、缺失ext-mbstring等扩展、vendor目录属主为root、镜像配置错误或CA证书失效；应先查php -v、composer diagnose、ls -ld vendor/及composer config -g repo.packagist。
Composer执行安装时提示报错，90%不是工具本身坏了，而是当前 CLI 环境的 PHP 版本、扩展、权限或镜像配置没对上——别急着重装，先盯报错关键词。
看到“PHP version does not satisfy”就别查网络了
这是最常被误判为“网络问题”的错误，本质是 php 命令对应的版本低于 composer.json 中 "php": "^8.1" 这类声明。注意：Web 服务器用的 PHP 和终端里跑的 php 很可能不是同一个。
- 运行
php -v和php --ini，确认 CLI 加载的是哪个php.ini - 检查
composer.json的require段，比如写了"php": ">=8.2"，但你本地是 8.1.3，就会硬拦住 - 临时绕过（仅调试）：
composer install --ignore-platform-reqs；生产环境必须升级 PHP 或降级依赖
报“Permission denied”写 vendor/ 或 composer.lock
这不是权限位不够，是目录“认错了主人”——vendor/、composer.lock 或 $(composer config --global cache-dir) 被 sudo 污染过，属主是 root，而你正以普通用户运行命令。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 报错里带路径的那一行就是线索：
file_put_contents(/path/to/vendor/autoload.php): Permission denied→ 问题在vendor/ - 立刻执行：
ls -ld vendor/ composer.lock $(composer config --global cache-dir)，只要任一显示root就确认归属错配 - 修复命令：
sudo chown -R $USER:$USER vendor/ composer.lock；全局缓存同理：sudo chown -R $USER:$USER $(composer config --global cache-dir) - 永远不要用
sudo composer install——它才是污染源头
卡在 “Resolving packages…” 或报 SSL/cURL 错误
这不是网络差，是 PHP CLI 缺必要扩展，或找不到 CA 证书，或系统时间偏差太大（>5 分钟），导致 HTTPS 握手失败。
- 运行
php --ini查出当前生效的php.ini路径，打开它，取消以下三行前面的分号：extension=openssl、extension=curl、extension=mbstring（ext-zip也要开，Composer 2.x 强依赖） - 运行
php -r "print_r(openssl_get_cert_locations());"，重点看default_cert_file是否可读；若为空或文件不存在，手动补证书并配openssl.cafile - 检查系统时间：
date，偏差超 5 分钟必须校准，否则 TLS 握手必败 - 验证扩展是否真生效：
php -m | findstr openssl（Windows）或php -m | grep openssl（Linux/macOS）
换阿里云镜像后还是连不上
镜像配置失败的根源常是书写错误、缓存残留或项目级配置覆盖全局设置。
- 正确命令是：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意中间有composer，结尾有/，且必须带-g） - 换源后必须清缓存：
composer clear-cache；Windows 用户还得手动删%LOCALAPPDATA%\Composer\cache - 删掉
vendor/和composer.lock——composer.lock里硬编码了旧 provider 地址，不删它，Composer 就一直重试失败路径 - 验证是否真生效：
composer install -vvv 2>&1 | head -n 10 | grep Downloading，第一行 URL 才是真实请求地址
最容易被忽略的是：composer diagnose 通过 ≠ install 能跑通。它不校验 composer.json 里 require 的 PHP 版本或扩展是否真满足，也不检查磁盘空间是否够解压 vendor——这些得靠 composer install -vvv 日志里 “Resolving dependencies” 卡住的位置来反推。
