运行 composer install 报错“Your requirements could not be resolved”本质是本地 PHP 版本、扩展（如 mbstring/xml/curl）或 platform 配置与 composer.lock 中记录的运行环境不匹配，需检查 php -v、composer diagnose 及 lock 文件 platform 字段，而非简单视为依赖冲突。
运行 composer install 报错，八成不是“Composer坏了”，而是环境没对齐、镜像没配对、或锁文件已失效——它本质是按 composer.lock 精确还原，不是通用安装命令。
报 “Your requirements could not be resolved” 不是依赖冲突，是环境不匹配
这个错误常被误读为版本打架，实际是本地 PHP 版本、扩展或 platform 配置和 composer.lock 里记录的运行前提对不上。
- 检查 PHP 版本：运行
php -v，对比composer.lock中platform字段（如"php": "8.2.10"），低一个 patch 版都可能触发 - 确认关键扩展启用：
ext-mbstring、ext-xml、ext-curl缺一不可；用composer diagnose直接标出缺失项 - 警惕
composer.json里的"config": {"platform": {...}}：它会强制覆盖真实环境，删掉或改成当前实际版本再试 -
--ignore-platform-reqs是临时绕过手段，装完大概率运行时报Class not found或undefined function
卡在 “Loading composer repositories” 或 “Downloading” 但没走镜像
镜像配置失败时，Composer 会静默 fallback 到 https://packagist.org，不报错也不提示，你看到的“卡住”其实是直连国外源超时。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 验证真实请求地址：运行
composer install -vvv 2>&1 | head -n 10 | grep Downloading，第一行 URL 才是它真正在连的地址 - 检查镜像是否写对：
composer config -g repo.packagist输出必须是完整 JSON，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；缺斜杠、少composertype、键名写成repos.packagist都无效 - 项目级配置优先级更高：只要
composer.json里有"repositories": []（哪怕空数组），全局镜像就彻底失效；临时清掉用composer config --unset repositories - CI/宝塔常见坑：你用
root配的全局镜像，但执行的是www用户；得用sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
报 “Failed to download … at tag vX.Y.Z” 是 Git tag 被删了
这不是网络问题，是依赖包作者把 v2.1.0 这类 tag 从 GitHub 仓库删了，Packagist 元数据还指着旧地址，结果 curl 请求返回 404。
- 先验证：用
curl -I https://api.github.com/repos/vendor/package-name/zipball/v2.1.0看是否真 404 - 别急着升版本：盲目改成
^2.2可能破坏行为；优先查该仓库 Releases 页面，找等效 commit hash（如#a1b2c3d）替代 tag - 若只有 ZIP 归档可用，在
composer.json根加"repositories"数组，用"type": "package"硬注入：{"name": "vendor/package-name", "version": "v2.1.0", "dist": {"url": "https://your-domain.com/pkg.zip", "type": "zip"}} - 必须用
composer update vendor/package-name --with-dependencies触发重拉；install不处理新 repository 配置
报 “Permission denied” 写 vendor/ 或 composer.lock
90% 是目录归属权错乱，不是权限不够。常见于用 sudo composer install 后，vendor/ 属主变成 root，而后续普通用户无法修改。
- 定位问题路径：报错里带
file_put_contents(/path/to/vendor/autoload.php)→ 就查vendor/目录 - 检查归属：
ls -ld vendor/ composer.lock；若属主是root，运行sudo chown -R $USER:$USER vendor/ composer.lock - Windows 下“Access is denied”多因杀软拦截 .bat 生成，或 PowerShell 权限模型冲突；改用 Git Bash 运行，或加
--no-scripts跳过脚本生成 - 别用
chmod 777暴力解——这掩盖了真正归属问题，且引入安全风险
最常被忽略的一点：composer install 成功只代表 vendor 目录结构完整，不代表能跑起来。autoload 没生效、类找不到、命令报错，往往是因为 vendor/autoload.php 没被正确引入，或 composer dump-autoload 没触发——别急着重装，先看自动加载链是否断在第一步。
