报错“could not find package xxx”主因是composer默认仅检索stable版本且不自动降级稳定性，需确认包存在、调整stability参数、正确配置私有仓库或等待镜像同步。

报错“Could not find package xxx”是稳定性约束拦路

不是包不存在，也不是镜像失效，而是 Composer 默认只查 stable 版本，且不自动降级稳定性。你看到的包可能还在 dev、beta 或 rc 阶段，或者作者压根没提交到 Packagist。

• 先确认包真实存在且可公开访问：打开浏览器访问 https://packagist.org/packages/xxx/yyy（把 xxx/yyy 换成实际包名），看是否 404 或显示 “Not found”
• 如果页面存在但 Composer 找不到，加 --stability=dev 试试：composer require vendor/package --stability=dev
• 若包托管在 GitHub/GitLab 私有仓库，必须在 composer.json 的 repositories 字段里显式声明 VCS 源，type 设为 vcs，url 填仓库 HTTPS 地址（结尾不能带 .git）
• 全局放宽稳定性限制（慎用）：composer config minimum-stability dev，这会让所有依赖默认接受 dev 版本，可能引发意外行为

项目里用了私有包却提示“could not be downloaded”

这类错误往往卡在认证或源配置上，而不是网络本身。Packagist 不提供私有包分发能力，Composer 必须知道去哪里、以什么身份拉取。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 确保 repositories 中的 type 是 vcs（不是 composer），且 url 是完整 Git HTTPS 地址，例如："url": "https://github.com/your-org/private-repo"
• GitHub 私有库需提前配置 Personal Access Token（PAT）：运行 composer config github-oauth.github.com your_token_here
• GitLab 私有库同理，用 gitlab-token 配置：composer config gitlab-token.gitlab.example.com your_token
• 若用自建 Satis 或 Private Packagist，type 必须是 composer，url 必须以 / 结尾，且该地址能返回有效的 packages.json

换源后仍提示“package not found”，其实是镜像没同步

阿里云、腾讯云等镜像源并非实时同步 Packagist，新发布的包可能延迟数小时甚至一天才可见。这不是你配错了，是镜像上游还没抓取。

• 别急着改配置，先去镜像站首页查包是否存在：访问 https://mirrors.aliyun.com/composer/p/provider-2024-07.json（年份月份按需调整），搜索包名关键词
• 如果镜像里真没有，临时切回官方源验证：composer config -g repo.packagist composer https://packagist.org/，再试一次 composer require
• 确认是新包后，要么等镜像同步，要么手动指定版本 + 直接引用 VCS：composer require vendor/package:dev-main --repository-url=https://github.com/vendor/repo
• CI/CD 中不要依赖镜像“一定有最新包”，建议把私有包或关键新包提前发布到内部源，或用 repositories 显式兜底

“Your requirements could not be resolved” 却和网络无关

这个报错出现在依赖解析阶段，说明 Composer 已成功连上源、拿到元数据，但本地环境无法满足锁文件或 composer.json 中的约束条件——它不怪镜像，只认 PHP 版本、扩展、平台配置。

• 运行 composer why-not php:8.3（换成你目标 PHP 版本），直接看到哪个包在卡住升级路径
• 检查 composer.json 顶部是否有 "config": {"platform": {"php": "8.2.10"}}，这个值必须和当前 php -v 输出一致，否则会被当作硬性要求
• 用 php -m 确认 mbstring、xml、curl、openssl 全部启用；CLI 和 Web Server 的 php.ini 可能不同，务必用 php -i | grep "Loaded Configuration File" 确认路径
• --ignore-platform-reqs 是临时绕过手段，不是解决方案；装完后大概率运行时报 Class not found 或扩展缺失异常

真正卡住的点，往往不在命令本身，而在 Composer 对“稳定”“平台”“源类型”的隐式假设——它不报错，只是安静跳过；它不提醒，只是默默 fallback。看清这些默认行为，比反复换镜像更管用。