composer require装稳定版需确保版本约束符符合semver且无@dev等后缀；^2.8实际等价于>=2.8.0，非仅2.8.x。
composer require 装稳定版必须写对版本约束符号
Composer 默认只装 stable 版本，但“稳定”不等于“最新”，也不等于“你心里想的那个”。关键在版本字符串本身是否被解析为 stable —— 也就是不能带 @dev、@beta 等后缀，且约束符要匹配 SemVer 规则。
常见错误是把 ^2.8 当成“装 2.8.x 最新版”，其实它等价于 >=2.8.0 ，如果 2.9.0 是 stable，就会装 2.9.0；但如果只有 2.8.5 和 2.10.0-beta1，它仍会选 2.8.5 —— 因为 beta 不符合默认稳定性门槛。
-
composer require guzzlehttp/guzzle:^7.5✅ 推荐：语义化约束，自动取满足条件的最新 stable 版（如 7.5.3） -
composer require monolog/monolog:~2.9.0✅ 锁次版本：只允许补丁升级（2.9.1 → 2.9.9），不会升到 2.10.0 -
composer require laravel/framework:10.42.0✅ 精确版本：必须存在对应 tag，且该 tag 是 stable（无 -alpha/-rc 后缀） -
composer require symfony/console:dev-main❌ 即使包有 dev-main 分支，也会报 “Could not find a matching version”，除非加--stability=dev
为什么 composer install 不会装你想要的稳定版
composer install 只还原 composer.lock 里记录的版本，完全不看 composer.json 里的约束。哪怕你把 "guzzlehttp/guzzle": "^7.4" 改成 "^7.5"，运行 install 也毫无作用。
真正生效的方式只有两种：
- 改完
composer.json后，运行composer update guzzlehttp/guzzle—— 它会重新解析约束，找满足^7.5的最新 stable 版并更新 lock - 直接用
composer require guzzlehttp/guzzle:^7.5—— 自动写 json、更新 lock、下载 vendor
注意：如果 lock 文件存在，require 仍会触发 update 流程；删了 lock 再 install，反而可能装出不符合你预期的版本（比如 ^7.5 解出 7.9.0，但你只想用 7.5.x）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
minimum-stability 和 prefer-stable 怎么影响“稳定版”选择
这两个配置不是开关，而是协同过滤器。即使你写了 ^7.5，最终装哪个版本，还得过它们的关。
"minimum-stability": "stable"（默认值）表示：所有包都只考虑没有后缀的版本；"prefer-stable": true 表示：当 stable 和非 stable 都满足约束时，优先选 stable。
- 两者都开启（默认）：
composer require guzzlehttp/guzzle:^7.5只会装 7.5.0、7.5.1 这类 stable tag，跳过 7.5.0-rc1 -
"minimum-stability": "beta"：允许装7.5.0-beta1，但前提是你的约束明确匹配（比如写"^7.5@beta"或"7.5.0-beta1"） -
"prefer-stable": false+"minimum-stability": "dev"：可能装dev-main，哪怕7.5.0已发布
别全局设 minimum-stability: dev 来图省事——它会让所有依赖都倾向不稳定分支，某天 symfony/http-kernel 更新一个 dev 提交，就可能破坏整个请求生命周期。
装完发现 vendor 里还是旧代码？检查这三件事
不是 Composer 失灵，而是流程卡在某个环节：
- 执行
composer require后没看到Installing dependencies或Writing lock file日志，说明自动 install 阶段失败（常见于网络超时、git config 缺失、vendor 目录权限不足） - 包已存在且当前版本满足新约束（比如你写
^2.8，而 vendor 里已是2.8.5），Composer 默认不重下，只更新 json 和 lock —— 此时需手动删vendor/guzzlehttp/guzzle再composer install - 运行
composer show guzzlehttp/guzzle，看输出里versions行是否包含你指定的版本；如果显示的是dev-main或2.7.0，说明约束没命中，或包本身没发那个 tag
最稳妥的验证方式是：删掉 vendor/ 和 composer.lock，只留 composer.json，再跑一次 composer install —— 这样能彻底排除缓存和残留干扰。
