composer require 失败是因为版本约束未精确匹配 packagist 或仓库中已发布的版本，composer 不支持模糊匹配，必须完全一致（含稳定性标记、前缀、后缀等），且需考虑锁文件、私有仓库配置及依赖交集求解。
composer show -a 能查到版本，为什么 require 还是失败
说明包存在，但你写的约束字符串没命中任何已发布版本。Composer 不会模糊匹配，它只做精确比对——差一个字符、少一个 @dev、漏掉稳定性标记（如 dev-main 必须配 @dev），就直接拒绝。
- 运行
composer show -a vendor/package，重点看 “versions” 列表里是否真有你写的那个完整字符串（比如2.3.1-beta.2和2.3.1是两个独立条目） - 打开 Packagist 页面，点 “Versions” 标签页，确认你要的版本是否在列表中、是否被标记为
abandoned或dev - 检查约束合法性：
1.2.*在 Composer ≥2.2 已移除；v2.0、master、latest全部非法；dev-main必须写成dev-main@dev
^ 和 ~ 看似相似，实际锚点完全不同
它们不是“松紧程度不同”，而是锚定坐标系不同：一个是主版本锚点，一个是主次版本锚点。写错一个符号，下次 composer update 就可能装上未测试过的 minor 版本。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
^1.2.3锚定主版本1，等价于>=1.2.3 ，允许升到 <code>1.99.0 -
~1.2.3锚定主次版本1.2，等价于>=1.2.3 ，连 <code>1.3.0都被硬拦 -
^0.25.0和~0.25.0行为一致——0.x 阶段 minor 升级即视为 breaking，两者都只放行0.25.x - 写成
~1.2实际等价于~1.2.0，不是>=1.2.0；^1.2同理，等价于^1.2.0
composer.lock 存在时，composer.json 的约束完全不生效
只要 composer.lock 文件存在，composer install 就只照着锁文件装，无视 composer.json 里所有版本字段。这不是缓存，是 Solver 上一次输出的「已验证可行解」。
- 改了
composer.json但没运行composer update，CI 构建仍会装旧版本，且不报错 - 误删
composer.lock后再install，可能装出和队友完全不同的子版本——这不是 bug，是约束太宽导致的必然结果 - 查真实装的是哪个版本，别只看
composer.json：运行composer show vendor/package -i
私有包 require 失败，往往卡在 git ls-remote 静默失败
私有包必须显式配置 repositories，且 URL 要能通过 git ls-remote 访问。写错 .git 后缀、漏 HTTPS Token、SSH 密钥未加载，都会静默失败——没有报错，但包就是找不到。
- 确认远程仓库真有目标分支：运行
git ls-remote https://github.com/vendor/package.git | grep refs/heads/main - HTTPS 私仓需带 Token：URL 应为
https://token:x-oauth-basic@github.com/vendor/package.git - SSH 私仓需确保
ssh-agent已加载密钥，且git@URL 可被git ls-remote正常解析 - 不要依赖全局
minimum-stability，私有包建议用"vendor/package": "dev-main as 2.0.0"显式映射
^2.0，另一个写了 ~2.5.0，最终装上的版本必须同时落在两个数学区间内——这个过程不可见，但失败时往往只报“no matching version”，得一层层剥开看。
