“your requirements could not be resolved”不是环境故障，而是composer.json版本约束与实际包版本不兼容，需用composer why-not定位阻塞包、检查minimum-stability和platform配置，并优先换国内镜像源排查网络问题。
composer install 报错不是环境坏了，大概率是依赖声明、网络或本地配置出了具体偏差——先别删 vendor 或重装 PHP，按错误类型对症查。
报错提示含 “Your requirements could not be resolved”
这是 Composer 解析依赖失败最典型的提示，本质是 composer.json 里写的版本约束和已发布包的实际版本不兼容。
- 检查
composer.json中的"minimum-stability"：设为"stable"却引用了"dev-main"分支，必然失败；临时改成"dev"可验证是否为此因（但上线前必须改回） - 运行
composer why-not vendor/package:version查哪个包在阻塞安装，比如laravel/framework v11.0要求php >=8.2，而你本地是PHP 8.1.28，就会卡在这里 - 留意
platform配置：若composer.json含"platform": {"php": "8.1"}，但实际 PHP 是 8.2，Composer 仍会按 8.1 解析兼容性，导致误判
卡在 “Downloading https://repo.packagist.org/…” 或超时
国内直连 Packagist 官方源经常 DNS 污染或连接不稳定，不是网络断了，而是请求发不出去或收不到响应。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行
composer config -g repo.packagist composer https://packagist.phpcomposer.com（已停用）或换阿里云镜像：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 确认是否启用了代理：如果终端设置了
http_proxy但代理不可用，composer install会静默卡住；临时清掉：unset http_proxy https_proxy - 某些企业网络会拦截 HTTPS 的 SNI 请求，可尝试加
-vvv看卡在哪一步，再配合curl -I https://mirrors.aliyun.com/composer/测试基础连通性
提示 “The process X exceeded the timeout of 300 seconds”
Composer 下载或解压某个大包（如 symfony/symfony 或含大量 asset 的前端包）时，默认 5 分钟超时，不是速度慢，是单步操作被硬中断。
- 临时延长超时：加参数
composer install --timeout=1800（单位秒），避免反复中断重试 - 跳过脚本执行（常是耗时大户）：
composer install --no-scripts，装完再单独跑composer run-script post-install-cmd - 禁用并行下载（某些旧版 libcurl 不稳定）：
composer config -g parallel.downloads 1
“Class not found” 或 autoloader 失效，但 vendor/autoload.php 存在
这通常不是 composer install 没跑完，而是 autoloader 没重建或 PSR 规则没生效。
- 删掉
vendor/composer/autoload_*.php和vendor/composer/autoload_classmap.php，再跑composer dump-autoload，强制刷新映射 - 检查
composer.json的"autoload"是否写错路径，比如"psr-4": {"App\": "app/"}，但实际目录是src/，类就永远找不到 - 开发中修改了类名或命名空间但没更新
autoload配置，dump-autoload -o会缓存旧映射，加--classmap-authoritative强制只读 classmap，反而暴露问题
真正麻烦的从来不是报错信息本身，而是错误堆栈里混着多个层级的问题：PHP 版本、平台配置、镜像源、autoloader 缓存、甚至 IDE 自带的 Composer 插件偷偷改了 COMPOSER_HOME。每次遇到先 composer diagnose，它比人更清楚当前环境到底信不信得过。
